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

In the following entries, you will read through the diary of a Mendix developer as they journey through a project from start to finish. As the reader, we can tell you that this project contained both triumphs, as well as tribulations. As you read, see if you can pick up on the indicators that signal the trajectory of this project’s journey. Within this series of entries lie invaluable lessons applicable to any Mendix engagement. I invite you to analyze these entries with a discerning eye, extracting actionable insights that could inform your own strategic approaches to Mendix development.

June 6, 2022

Today I was told that I might get put on a client at the end of this week, pretty exciting stuff! What I know so far is that our sales team has scoped out for a 6-month engagement and the SOW looks pretty involved. Seems like there will be three of us working with this client to build them an app that essentially clones their existing application but makes it better along the way. We have a meeting tomorrow to go over the SOW items before we get started…

June 7, 2022

Just got off a 2-hour call with management… that was exhausting! I didn’t realize how complicated their business is, they generate so many different things in their current app based on all sorts of configuration. I spoke to my Sr. Architect to see what the best way to programmatically generate all the docs would be and it sounds like there may be a ton of backend logic to process any given set of requests. I’m going to see if the client can send me a dump of their database data to see what it looks like, maybe I can get a better idea of what we are up against here.

June 8, 2022

Got an Excel dump of their data this afternoon and all I can say is WOW… This is a lot of very dirty data. I’m not sure they have any validation in their current application at all. At least we got the SOW signed this week though, we will be starting development this coming Monday! I think we have our work cut out for us over the next 6 months.

June 13, 2022

Started development today and we are absolutely crushing it, we got the first sprint all planned out with about 40 points of stories and finished the login page and some of the basic navigation. 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. They said that looks so much better than what they currently have so “just make it look nice using those assets”.

June 17, 2022

First week is going really well, we almost finished the 40 story points we set out to complete this sprint so we added in another 20 points going into next week to fill the sprint. We told the client that the sprint planning and estimates will fluctuate a little for the first few sprints till we can better understand how fast our dev team can complete story points. 40 seems like we were far too conservative with our estimate so lesson learned there, we will load up more points for sprint 2.

June 24, 2022

This second week went very well once again, the client is loving our progress already on the app. We demoed the basic layouts and page features we finished this sprint and the client is very excited to get more built. 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.

July 8, 2022

Lost my diary last weekend… glad I found it today in the clutter on my desk. Sprint 2 was actually very frustrating because of all the changes the client wanted on the page designs. Their current app has a pretty complicated matrix to display their signoffs and we just used a Data Grid 2 to allow the user to filter and sort the data that way. They wanted it to look exactly like their current app so we had to re-do it with a pretty hacky set of triple-nested list views and some custom styling to make it look right. Really glad to have had a css expert step in to get the styling working on this, my first 2 attempts would be misaligned by a SINGLE PIXEL and it was driving me nuts. I’m so glad it’s Friday, got an hour back because the client canceled our sprint review — they had some issue to deal with so we are reviewing before sprint planning on Monday…

Let’s stop reading for now, time to analyze!

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:

Comfy, yet slightly concerned.

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.

Look out for the next set of entries from this developer to see how things can go from good, to bad, to ugly… to good! Send me an email if you see any other topics of conversation from my article here, would love to chat about them or any of your current projects.

Email Me!

luke.bashford@kinetechcloud.com

This post was originally published on medium.com and can be viewed, here. 

Mendix-1.png
9 Pro Tips for Starting with Mendix
Image of kinetech
kinetech

This post originally appeared on Mendix.com November 12th, 2013.

Thanks to Mendix’s continued rapid...

The Diary of a Mendix Developer: Part 2 — How it’s going
Image of Luke Bashford
Luke Bashford

Continued from Part 1

Living On The Edge: Mendix On An Embedded Device
Image of Kyle Kunzer
Kyle Kunzer

I was recently asked about Mendix in the context of Edge computing; that is where an application...