Using Trello and Google Forms to organize a conference

by Johannes Brodwall Posted on September 28, 2017

We’re running Mobile Era for the second year on October 5th-6th and I’d like to share some experience on how we’re using scripts and Trello to help with the organization effort. If you’d like automating simple tools, this is the article for you.

If you haven’t signed up for Mobile Era yet, you can leave a comment in this blog post for a discount code!

Google Forms is great! You can simply design pretty advanced forms and easily get responses. But after you get the responses, it’s a bit trickier. Similarly, Trello is great: Once you have your tasks in place, you can work on them easily by dragging and dropping. We decided to combine them with a little bit of script magic.

For a conference, one of the big tasks is to collect talk submissions and select who should get to speak at the conference. Here’s how we did it:

  1. A potential speaker submits a talk in our Google Forms call-for-presentation.
  2. Our magical script creates a card in a Trello board for the talk
  3. If the speaker updates the talk, the Trello card gets automatically updated (and marked with a special label)
  4. The program committee can comment on the card and move it around, safe in the knowledge that any work they do will be preserved even if the speaker updates the card

I started doing this with Trello’s email integration, but this fell apart when I wanted to update existing cards. Now I use the Trello API instead (there is a Zapier integration that has the same limitation, too). Here is the source code for my Google Forms script.

This is how you use it:

  1. Create a Trello board with an “Inbox” list and a “Updated” label. You will need to find Trello’s ID’s for these, which I leave as an exercise to the reader.
  2. Create a Trello API key and token at https://trello.com/app-key
  3. Create a new Google Form and set it up with the fields that you want
  4. In the Forms editor, open the “…” menu and select “Script Editor…”
  5. Copy the text from my gist into the Script Editor
  6. Update the autentication, idBoard, inboxList and updatedLabel values with the IDs from your Trello account
  7. Update “getCardName” and “getCardLabelIds” to include relevant fields from your form
  8. Run the function “sendAll” to send any existing form submissions to Trello. This will make Google Forms ask for permission to store the links between Trello cards and Form submissions.
  9. Add a trigger to “saveToTrello” on “On form submit”

The clunkiest part of the code in the gist is probably finding the values of a defined form field. This is also brittle if the form is changed, but what can you do, eh?

I’ve also started using information Trello to merge emails and save drafts for easily editing and sending. But that’s a story for another day.

A little bit of script can save a lot of tedium and help you extend tools like Trello and Google Forms to work together. I welcome your comments on how the script could be made even better!

Posted in Communities, English, Software Development | Leave a comment

How I learned to love GDPR and so can you

by Johannes Brodwall Posted on September 7, 2017

If you are working with software development as a developer, manager or tester, then you will be impacted by the General Data Protection Regulation (GDPR) – the new EU laws regarding data privacy. In many ways, the regulation is likely to have as big of an impact as the Y2K problem. But this time it’s because of a good cause! And you cannot ignore it, as the fines for doing so can be crippling. But for most people who find themselves face-to-face with GDPR it’s quite intimidating.

I hope this article can do something about that.

First, let’s say a few words about how to approach the regulation itself and then let’s look at some actions you should consider. I find the text of the regulation to be surprisingly well-written, but I wish I had a reading guide when I started out.

The actual text is officially published on http://ec.europa.eu. The text starts with 173 “recitals”. These are background considerations for the regulation. Even though they are well thought out and well written, they are not very much to the point. They are also often quite heavy to read, even if it’s for good reason (a perfect example is Recital 38 which talks about the data protection concerns of children). After the recitals are the actual 99 articles of the law, which are much easier to read. These are divided into chapters and many of the later sections are about the structure for enforcement, not for the actual regulation as it impacts most organizations.

Instead of reading the PDF, I recommend looking at https://gdpr-info.eu, which has organized the regulation in an easy-to-use structure. If you are responsible for an IT system, you need to understand at a minimum articles 1 through 50 and especially articles 5 through 35. Start by reading these.

Let’s look at some of the ways you may be surprised.

Surprise 1: Consent and test data

In order to collect and use personal data, you need to have permission to do so (article 6). For most people, this either means that you are required by law to use the information (for example medical information in a public health context) or that you have obtained consent from the data subject. This has actually been the case for a while, but some things will be more explicitly required: First, you must make it clear what your user is consenting to and second, you must make it optional (and non-default!) to give consent in cases where it’s not needed to provide a given service.

One very common scenario is for organizations to use production data from their customers for testing purposes. You can forget about that in the future. You could ask your customers for consent to use their data for testing purposes, but you must make this consent optional and non-default. So that means that at best, you need to find good routines to extract only data for consenting customers. Good luck! You could anonymize the data, but you are liable if there is a risk of reidentification.

Instead, I recommend that you invest in other testing strategies. In particular, most testing organizations can improve a lot by creating synthetic data. By investing in synthetic data, you can also improve your ability to stress the system with large and unusual values. Another testing method is partial production, where you gradually let more users onto a new version of the system. Perfecting this will also improve your delivery cycle a lot.

Now you have an excuse to invest in better testing.

Surprise 2: Functions required to support the rights of the data subject – data portability

When you store personal data, you now have to plan for functionality where the subject of this data can exercise their rights regarding the data. Much of this has already been the case, but the existing rights have been strengthened. This is described in articles 12 through 23. Just add them to your product backlog as system functionality or manual processes that must implemented. Basically, your customers have the right to see what data you are storing about them, including who has accessed the data. They should be able to correct errors in the data and to ask for data to be deleted.

A new and very interesting right is the right to data portability (article 20). Your customers have the right to get their data from you and take it to your competitors in a portable format (“structured, commonly used and machine readable”). As I understand it – if your customers can get an exported JSON, XML or CSV-format with everything concerning them, you’re pretty much set. If you wonder: PDF is not good enough.

Data portability is one of the most exciting parts of the GDPR and seems to be motivated by a desire to promote innovation. Just imagine what you can do with it! Imagine an app that can import your purchase history from all major store chains and help you analyze your own buying habits. It’s long been a dream, but the data was locked up. Until now!

Or you can use it to keep your competitors honest! Tell your customers that if they give you consent and upload their data from your competitors, you give the discounts and prizes. You have to be prepared for the case that your customers withdraw their consent again, but you are still allowed to keep aggregated data. And if you’re competitors are laid-back about GDPR – well, you can really put their feet to the fire!

Surprise 3: Keep data safe during transfer and storage – everywhere!

The final important consideration I want to talk about that comes out of GDPR is keeping data safe and under control (article 32 and also article 25, which mandates Privacy by Design). You are required by law to protect personal data in transit and rest at all locations. You are also required to report to the local authorities any breach of data that you detect.

What you need to do now is to map out every place you transfer personal data. What about temporary storage areas? What about backups? What about third parties that receive data? And what about logs?

Most organizations have less access protection of application logs than any other data. And often you log without considering the contents of the logging. I used to practice an approach of logging the full payload of all incoming and outgoing communication messages. That may no longer be a good idea.

The easiest way to protect data is to make sure you never collect it, and failing that, making sure that you don’t store it unnecessarily. You need to trace every piece of personal data through your systems and find out who can access it. If you can collect less, that will make your job easier.

Get started

There are more aspects of the GDPR that I have not discussed. In particular, the role of the Data Protection Officer is critical and has some surprising nuances.

But the goal of this article was to give you a place to start where there’s a good chance that you have something you need to do and perhaps something that you can benefit from as well. Here are three suggestions: 1. Verify that you’re not using production data for testing and develop new testing techniques if you do, 2. Add development tasks to support the rights of the data subject – a good place to start is Data portability, 3. Analyze the flow of personal data through the system, especially looking for less secured storage locations like logs and temporary files.

It’s not long until the law comes into effect and you need to get ready! The three places I’ve pointed out where you need to start touch most of the IT system related aspects of GDPR and can be used as a basis for understanding, implementing and benefiting from our improved rights to our own data as citizens and individuals!

Posted in English, Non-technical, Software Development | 3 Comments

Deliver early without sleepless nights

by Johannes Brodwall Posted on April 21, 2017

Trailblazing the first delivery of a software system requires courage and conviction, especially on projects that replace existing business critical software. When I’ve been acting as system architect I’ve employed a number of tricks in order to structure functionality and technical solutions in such a way that we can complete these early deliveries without sleepless nights. The most important is to find a subset of functionality that can be used with the rest being completed and investing in bridges from the old to the new.

Next Thursday (April 27th), I share my experience in the keynote for the ARK architecture conference in Oslo. A few tickets are still available if you want to make it.

In this blog post I explore the topic of replacing business critical software step by step.

As an architect I haven’t always have the joy of seeing my projects all the way to completion, but in those projects where I can see the software in the hands of my users early on are those I enjoy the most.

This article is not about streamlining a working delivery team to get from releases every few months to continuous deliveries. Many others talk about that. This is about how to get to production early the first time on a greenfield project. I will illustrate with two of my favorite projects.

Getting to the production the first time on a greenfield project takes courage and conviction, especially when you’re replacing part of business operations with a new system. Project stakeholders have many reasons to wait and often see no compelling reason to delivery a partial solution early. But when you get to production the first time, it’s like the sun has finally risen. The priorities and discussions in the project totally change. Now it’s real!

The first project I want to talk about was with the Norwegian electricity transmission system operator Statnett. We spent 4 years replacing the system that handles all reserve capacity of electricity deliveries on the Norwegian grid, but less than a year after the contract was signed, the users started using our software to control the power grid. Without any sleepless nights. Actually, they considered it such a non-event that they forgot to inform the development team about it!

The second project I would like to talk about is an app for internal mobile workers in private sector. As it is a project which is part of the competitive strategy of my customer, I cannot mention the purpose of the software, but I can describe techniques and technologies.

mobile workforce architecture

The mobile workforce app is especially interesting. Just like with Statnett, we were replacing an existing system in business use and integrated with other business functions. But in this project, we were live with the first users after 3 months, most of the user base after half a year and the remain users after around 9 months.

Here is what we did:

  • Realize that the journey is going to feel long and temporary investments made to ease the journey are often worth it. In both cases, I made sure the new system integrated well with the new system. I cannot stress how much it lowers everyone’s stress level when you can say: Why don’t we try the new system and if you experience problems, you can continue the very same process in your old system.
  • Isolate functionality that is small enough to deliver with a small fraction of the total project effort yet interesting enough to care about. In the case of Statnett we were able to replace the most used feature in the old system (while preserving the path of retreat). Even though the feature was a small part of the system, it was a large part of the usage. In the mobile workforce app, we found a business process that was missing in the old system and implemented this first. The process was interesting enough to the customer that they dedicated a few users to only perform this task.
  • Don’t wait for the rest of the world to complete their work. All projects I’ve been on has been part of a larger landscape of change where several of your dependencies are still under development by other projects. In the case of the mobile workforce app, we were dependent on core data that was to be owned by a system still under development. Realizing that our integration model would in any case be based on synchronizing copies of data, we decided that our copy of the core data would have several sources: 1. A manual CSV file exported by a sysadmin, 2. An automated dump from the legacy source which we established after half a year, 3. A feed from the new system (which is still not completed).
  • Spend effort making your system faster to deploy and easier to monitor. When you make a greenfield project, there is actually nothing that stops you from creating the production environment immediately (as long as you don’t put production data there before it’s hardened!). I’ve never regretted spending a few extra hours making it easier to deploy new version or making my logging smoother. Currently, I receive error logs on Slack with a clickable stack trace and a link to the user who experienced the problem.

When you do a major rehaul of a building, you may end up spending a lot of your effort setting up the scaffold to make sure the work is safe and effective. When you build a new software system, you should do the same!

If you do, you may be able to get users on your new system sooner rather than later without losing your sleep.

And when you get actual users to use your system the primary question of the project changes from “when is it all going to be done” to “what can we do next to deliver value.” And that’s much more fun.

Posted in Agile Release Patterns, English, SOA, Software Development | Leave a comment

“No – you don’t understand…”

by Johannes Brodwall Posted on October 21, 2016

On the futility of understanding

Is true understanding actually possible? I use my fingers to tap out keys on a keyboard and the light from your screen hits our eyeballs, but is it reasonable to think that there is any correspondence between the patterns in my brain and the patterns that were just created in your brain? Or are we just lucky if we have the same thoughts?

I used to think that if I just used the right words and asked the right questions and if only those I spoke with responded with the right words, then I would really understand what I needed to know. In software development projects I thought I would understand “the Requirements” (insert chorus of angels here). Either, the futility of understanding har recently dawned on me, or mind brain recently got out of focus (which is not unlikely: after my second child was born, my sleep deprivation is way up and my level of intellectual stimuli is down).

In short: I just realized I don’t really understand what others are saying to me. But maybe that’s okay. I’ve given up on understanding, but I don’t let it stop me. When my users tell me what they need, I listen, but I probably don’t really understand. I ask some questions and I get some answers, but not really answers to what I had in mind when I asked the question. So I retreat to my computer. Think a little. Sleep on it. Then I make something I can show my users without spending too much time. I see in their faces that they like it. Or don’t like it (which, to be honest, happens more often). I think some more. I create something different. In the end, I think my users are happier and more productive.

Would the process be improved by a Business Analyst on the project? I don’t know. I probably would understand the Business Analyst either. I would have someone to blame when I got it wrong. But would I get fewer things wrong?

Would it be better if someone had sat down and written a “Requirement Specification” (again: choir of angels)? I don’t think so. I usually feel even more lost when I read a spec than when I talk to “confused” users. (Disclaimer: The users are not really confused – they just seem that way from my point of view)

Perhaps we all really are walking with a blindfold in this world and we are just feeling our way around in the dark. The blindfold is not coming off any time soon. Perhaps it’s just as well we learned to live with it.

PS: If you didn’t understand the point of this blog post: That’s my point!

PPS: This seems like a philosophical position that someone must have thought a lot about before. I’d call it epistemological fatalism. I’d love to get tips to prior ideas in the comments.

Posted in English, Non-technical | 2 Comments

What mobile strategy is best: Native or Hybrid?

by Johannes Brodwall Posted on October 7, 2016

So: What is best? A native app or a hybrid app? And if you build a hybrid app, what’s the best framework to use?

As with most interesting questions, it turns out that the answer is “it depends”. I often get questions like “isn’t Xamarin (or Cordova) better than build a native app”. Weeeell, it’s not as simple as that.

Here’s a few ideas that I’ve found myself repeating lately:

  • Are you building something that should be available to a large audience where you also want a (mobile friendly) web site? Then Cordova is probably worth a look. Actually, if you get the Progressive Apps parts right, you may want to use Cordova for iOS and a “pure” web app for Android. If you’re building something for an event (like a conference!), mobile web should probably be a strong consideration. People don’t like to download an app that they will only use for a specific period.
  • Are you building an app to internal users in the company where you can control what device they use? Then you may want to consider targeting a single native platform (either iOS – if you don’t think companies should pay taxes – or Android – if you feel that mobile devices can never be too inconsistent). CSS + JavaScript has a lot of sharp edges and adding a layer of abstraction on top of a programming model also adds a layer of obfuscation. If you can get away with targeting just one platform, then go native!
  • Also, if you want to go for absolute top-of-the-class, you probably want to build (two) native apps. Anything that wasn’t build with the native SDKs will probably feel a little foreign and weird on the device. At the very least, hybrid frameworks usually trails a bit behind the newest platform developments. This means two code bases, two copies of every bug and quite possible two teams (or 2 + a backend team). You pay for style!
  • If you want something that doesn’t have to be spit-and-polish perfect but that should still feel well integrated with the respective devices and you don’t want to invest in two separate code bases, then Xamarin or NativeScript may be a good bet.
  • Finally, you always want to consider the skillsets of the team at hand. If you want something native-looking and have a bunch of JavaScript developers, NativeScript and ReactNative are your friends. If you have a bunch of C# developers, then go for Xamarin.

As a mobile developer, there’s always more stuff you should learn. This is why I co-founded the Mobile Era conference which happens in Oslo November 3rd-4th, where we will have talks on Android, iOS, ReactNative, Ionic 2, as well as IoT, beacons, mobile databases and much more. Tickets are soon sold out at mobileera.rocks

Posted in Communities, English, Mobile, Software Development | Leave a comment

Welcome to the Mobile Era

by Johannes Brodwall Posted on October 4, 2016

(Looks like I’m back in the conference organization game again! After a few years of lots of travel and then a few years of lots of family responsibilities, this year I co-funded the Mobile Era conference. It looks like it will be a blast!)

If your experience is anything like mine, most of the interesting projects around you are having a larger mobile component this year than last year. I think this trend will continue. It can be a mobile-first website or a custom internal app for a company that wants their workers to be more effective when they are in the field. It can be an app to engage your customers or an intelligent sensor or “thing”.

We now have the technology to move lots of applications that used to be tied to a workstation over to a mobile device and in so doing unshackle people from their desks.

But this leads to a new challenge for developers: If you were an “enterprise developer”, you’re used to large data volumes, complex domain models and integration with various systems in various degrees of disrepair. If you were an “apps developer”, you were used to multiple device configuration, designing for small surfaces, and APIs with various peculiarities. Now the need has come for people who combine those skills.

With this in mind, it dawned to me almost a year ago that there is no good event in Norway that addresses this challenge. I wondered if anyone else was thinking like me, so I send an email to a few people with “if you think this is cool, I’m meeting a couple of people at Espresso House next Monday to see where we want to go. Please forward.” I was pretty amazed by the turnout (I’m the guy hiding in the back):

Mobile Era team

When we compared notes, many of us had almost identical ideas about what we thought a Mobile conference could mean. In the front and center of the picture, you can see Maxim Salnikov who came up with the name that embodied everything we had in mind. Thus the Mobile Era conference was born.

After a long and winding road, Mobile Era is only a month away. We have an amazing program with deeply technical subjects like the Realm Mobile database, Mobile DevOps, the new Awareness API in Android, performance tuning in Swift, ionic 2 features, React Native, Firebase, IoT. If you wanted to catch up on what’s happening all over the Mobile space, now is your chance!

When I look at my own preferences, I see that I more and more often leave the computer behind and use my mobile instead. I do code review on my mobile, I watch tech talks on my mobile (as well as tv), I receive production logs on my mobile, I deploy the next version of my software on my mobile.

In the Mobile Era, I expect my users to demand as much from the software I write.

PS: The early bird closed last week, but if you write a comment on this blog post, I’ll email you a special discount code which is valid for another week or so.

Posted in English, Mobile, Non-technical, Technology | 3 Comments

Computer vision for Java developers

by Johannes Brodwall Posted on September 13, 2016

At JavaZone this year, I gave the talk “Computer Vision for mobile Java developers”. Here, I live code finding conference badges in a picture. The coding is iterative and interactive and I use it to illustrate Haar cascades, Canny edge detection, Otsu thresholding, contour detection, erosion and dilation and contour analysis.

In my experience, developing a good algorithm with OpenCV is about setting up yourself for feedback. I read an example image, add one and one processing step to it and display the results as I work. This both works well as a development technique and is a good framework to explain what’s going on.

If you’re looking for an entertaining and practical explanation of OpenCV image processing, this talk covers a lot of ground.

Posted in Uncategorized | Leave a comment

Hva burde egentlig et norsk IT-prosjekt koste?

by Johannes Brodwall Posted on February 11, 2016

Er det noen som sammenligner omfang og kostnad på IT prosjekter i Norge? Jeg tror man kunne få noen interessante innsikter dersom man gjorde dette riktig.

(Jeg må unnskylde at teksten i denne blogposten blir litt vag – jeg ønsker å si så lite som mulig om de aktuelle prosjektene for å unngå å eksponere andre)

Akkurat når jeg var involvert i et tilbudsarbeid for et prosjekt, var jeg samtidig involert i den endelige godkjenningen av et annet prosjekt. Jeg stusset over den store forskjellen i kostnadsramme for disse to prosjektene. Problemstillingen gikk lenge og gnagde og etter en lang tid ble jeg bevisst på at de to prosjektene hadde nesten helt likt forretningsmessig omfang. Hvorfor hadde de så forskjellige kostnadsforventninger?

Begge prosjektene var løsninger som hadde noen hundre saksbehandlere spredd i noen titalls lokalkontorer som behandlet noen titusentalls forretningstransaksjoner i året. I begge tilfellene var det cirka 20 forskjellige typer forretningstransaksjoner og disse hadde cirka 50% like behandligssteg, cirka 25% av behandlingsstegene var sammenlignbare og cirka 25% av behandlingsstegene var unike per type forretningstransaksjonene. Begge prosjektene skulle produsere og arkivere dokumenter og integrere med en håndfull andre systemer i og utenfor virksomheten.

Føringene rundt teknologi, arkitektur og prosjektledelse var nok forskjellige i de to prosjektene. Men omfanget av hva de skulle gjøre virket for meg veldig sammenlignbart.

Og forskjellen i kostnadsrammer? Jeg har ikke tilgang til offisielle budsjettall for de to prosjektene, men vi snakker om en faktor på 5x-10x. Dette er dramatisk.

Er det noen som har gjort en systematisk objektiv innsamling av IT-prosjektene i Norge? Ville ikke dette være et interessant forskningsprosjekt?

Posted in Non-technical, Norsk, Software Development | Leave a comment

Er IT-prosjektenes tid forbi?

by Johannes Brodwall Posted on October 9, 2015

Man kan lese fra moderne tanker på IT-utvikling at prosjekter er en avleggs arbeidsform. For de som har erfaring med utviklingsaktiviteter innen offentlig og privat sektor kan dette virke som en rar påstand. De aller fleste ser behovet for å unngå store prosjekter, men er prosjektet som arbeidsform virkelig avleggs?

Det spør naturligvis på hva man mener: I alle de årene jeg har jobbet med IT-utvikling er det en ting som er sikkert. Arbeidet endrer seg til det bedre når man går fra å bygge noe på laben og over til å lansere programvaren for brukere som benytter seg av den til daglig. Før dette tidspunktet er “kvalitet” en subjektiv og spekulativ egenskap, “fremdrift” er et begrep som må kvalifiseres med mange forbehold og formålet til hele initiativet er fortatt en hypotese der alle har sin egen tolkning.

I dag er den ingen gode grunner til å levere programvare gjennom et prosjekt som sitter flere kvartal eller år og bygger noe som så skal være klart til en stor lanseringsdag. I den betydningen er prosjekter en avleggs modell.

Men noen ting har ikke endret seg: Mange organisasjoner vil ha behov for et team som er større i en periode – et prosjektteam. Mange organisasjoner kunne ha verdi av leverandører som kan ta ansvar for at det arbeidet som gjøres er av god kvalitet og har en rimelig kostnad.

Men organisasjonen gjør smart i å koble dette prosjektteamet tett opp mot den mer permanente organisasjonen. Linjeorganisasjonen kjenner behovet og rammevilkårene bedre enn den midlertidige organisasjonen og vil ta over forvaltningen av produktet på sikt.

Og nye produkter vil ikke lanseres dager eller en gang uker etter at de har blitt påbegynt. Ved å levere så ofte som hver uke eller endog flere ganger om dagen kan organisasjoner heve kvaliteten og redusere arbeidet og bekymringen i forbindelsen med nye leveranser. Men det er ikke gjort på en dag. Dersom man skal etablere et nytt prosjekt kan man med fordel drifte dette (for eksempel i en skybasert løsning) allerede etter få dagers utviklingsjobb. Men det vil ta noen måneder før man har nok funksjonalitet til at man ønsker å invitere noen utenfor prosjektet til å bruke løsningen.

Er IT-prosjektenes tid forbi? Jeg håper vi ikke lenger vil se initiativene som bruker titalls eller hundretalls millioner kroner før man lanserer noe for brukere. Men organisasjoner vil fortsatt måtte benytte seg av økt bemanning i satsningsperioder. Og nye produkter bygges ikke på en dag før de kan lanseres.

Posted in Agile Release Patterns, Non-technical, Norsk, Software Development | Leave a comment

Are you getting worked up over code duplication?

by Johannes Brodwall Posted on June 10, 2015

As programmers, we have long learned that Duplication is the Ultimate Sin of programming. Even considering to duplicate something is almost unthinkable.

But removing duplication introduces dependencies. If you and I use the reuse the same piece of code instead of duplicating it, changes I make may affect you. This effect can anything from beneficial (I fixed a bug you also needed fixing) to benign (I added a new feature that you’re not using) to detrimental (I want it to work in a way that’s no good for you).

When we have dependencies, we have to think: “Perhaps I shouldn’t add that feature – what if breaks something for someone else?” “Damn the torpedoes, I’m hacking it in!” or “Perhaps I’ll just make a fork for my changes and we’ll merge later”.

Sometimes benign, sometimes harmfull.

I recently discussed with a friend the case of being innovative in the face of legacy code. Remember: Legacy code is code that you don’t want to touch, because it’s dangerous to change and it gives value to the business now.

We want to gradually build a new platform. So it seems like we have two choices: We could make the new code call functionality on the old platform (ick! because, you know, “stop digging“) or we could build a new service and change the old system to use it (OMG! because, you know, “dangerous to change”).

If we allow the new system to duplicate as much functionality as needed from the old system, this false dicotomy goes away.

Duplication isn’t a cardinal sin. It’s a negative property, but in many cases, it could be your best option.

Posted in English, Software Development | Leave a comment