The Diary of a Mendix Developer: Part 1 — How it Started

By now I would hope you have a few observations or insights just from these few entries above, some more concerning than others. Perhaps you are beginning to feel like this pug:

Let’s quickly talk about some things that stand out to us:

Our sales team has scoped out for a 6-month engagement and the SOW looks pretty involved

As a developer, we seem to have been left out of the scoping process altogether. This developer saw the SOW and their first reaction was that it looks very involved. They later comforted themselves by saying they have 3 developers working on it and assumed it should be fine. Speak up if you think something seems off, having a discussion should be the bare minimum requirement when you have any indication of scope being inaccurate.

I didn’t realize how complicated their business is

Before even starting development, this should raise some concerns. We see this happen quite often in the low-code world where a client or delivery partner will gloss over the fine details of a project early on with the assumption that the combination of rapid development and Agile methodology will fill in the gaps along the way. We know from experience that this just doesn’t work. Call it poor planning, scope creep, bloat, whatever you want… the fact of the matter is as soon as a developer sees signs of a project requiring more effort than the team initially thought, it’s time to start managing expectations and organizing the core scope of work in a way that delivers value at regular intervals without jeopardizing the overall goal of the planned SOW.

I spoke to my Sr. Architect to see what the best way to programmatically generate all the docs would be

Always use your network when dealing with problems you may not know the best solution to. The Mendix ecosystem is full of incredibly talented and experienced people. We are all better off spending less time trying to figure something out, and more time reaching out to see if someone can provide any advice to help us arrive at a solution faster and more efficiently.

WOW… This is a lot of very dirty data

This is something that can be VERY hard to plan ahead for, especially if you are working with a client that has a lot of non-technical people on the project. In a perfect world, all data would be validated and easily useable by a Mendix application. Breaking news! We are not in a perfect world and the clients that often need Mendix development are trying to solve this exact problem. At this point early in a project, when the data is immediately viewed as a potential issue, it would be wise to bring this up with your architect and then set up some time with the client to plan around cleaning and migrating any data to the new application.

The client decided they don’t want to provide any branding or UX/UI direction and instead trust our judgement to make it look nice after seeing the default Atlas UI

You ever hear anyone say “CYA”… this is one of those moments. It is very easy to respond favorably to a client relinquishing control of UX/UI design, however, you must document these decisions along the way. Giving a developer creative control is wonderful but far too often when it comes time to deliver a demo, the client will suddenly have very strong opinions about the design choices and work may need to be redone. Plan everything!

Their SME had some great ideas to expand on the backlog items, we are taking note of these and putting them into related stories so we can pick them up as V2 items, or when we have remaining time to do so.

A WIN! This is a fantastic approach to managing a backlog and putting feedback in a place where it doesn’t add any risk to the existing project. When a client gives feedback on deliverables, this feedback needs to be looked at as net new content, documented, and placed at the bottom of the backlog so as not to disrupt the progress toward delivering value to the client.

Lost my diary last weekend… glad I found it today in the clutter on my desk

Stay organized — This goes for your product backlog, your email, and most of all your physical space. If you have junk all over your desk it’s a telltale sign that you are becoming stressed, disorganized, and careless. Take a few minutes each day to make sure that you set yourself up for success, especially if you are working from home. Your physical workspace affects your mental workspace and will be reflected in the quality of your work more often than not.

They wanted it to look exactly like their current app so we had to redo it with a pretty hacky set of triple-listed list views and some custom styling to make it look right.

OHHH, so NOWWWWW we have opinions!!! I think this was the clearest red flag out of these early entries. This dev was told they had creative freedom, they built a feature that worked, but upon delivery, the client decided they didn’t want it this way and now we just wasted time and budget building something the client doesn’t like.

How do we avoid this? Well, rewind a few entries and look at the other small gaps in planning. Any single item may seem insignificant enough, but together they paint a bigger picture. As experts, we can’t get complacent with our clients or the work we do. Everything that goes into a project matters, especially over a longer period. The project in this case was scoped for 6 months and already 3 weeks in we have seen a half dozen small problems that seem innocent enough. However, what are these going to look like 4 months from now… Always document decisions, stick to the planned requirements, and make sure any changes in scope are handled in a way that doesn’t add risk to the overall goal.