Enterprise Web Development - Why so hard?

I have noticed a trend in several enterprise-level projects during the last few years. I think software engineering teams, mostly in the web application space, are having difficulties delivering high-quality and reliable solutions. I know we have smart people - however, I think we are getting in our own way. We think that some of these processes like Agile Scrum/Kan Ban, ScrumBan or whatever is the golden ticket to success.

I think the process is failing our people (developers). Agile principles seem to be far removed from our current/modern approach within large enterprise teams. I guarantee for most teams it is "process over people" and not "people over process". Do we really value working software over process? Especially troublesome, is the hand-off from product teams to developers - our user stories are horrible. Are user stories the right way to organize work and describe what needs to be done?

Is Web Development Really this Difficult?

It is the year 2022 - have you wondered why web development or creating web applications is so difficult? You would think that after a couple of strong decades of web application development along with the tools and processes available today – that we should be better, faster, and more effective in our application development.

But this is not the case. Even though we have better tools and process, there’s still a missing element from web application development. It is up front design for the front end. We have amazing tools, frameworks, platforms - like Angular from Google. What we really need is a workflow that includes architecture along with analysis and design.

What do I mean by this? Architecture has a lot of different meanings in software. So, let’s break it down using what we know about its origin. Throughout the millennia of time, humans have built amazing structures that have lasted for centuries or thousands of years. How did this happen? The Eiffel tower in Paris, the pyramids in Egypt, the Arc de Triomphe in France, and even the beautiful modern skyscrapers that are built today. All have one thing in common. What is that?

Before any of these projects were executed, I mean before someone started building and constructing them there were phases that included analysis and design. What do I mean by analysis and design? It is going through the thought process of what you are going to build, why you need it, who is it for, where will it be used, when will it be used and why will they use it or find it beneficial? It is going through the thought process of answering all of these questions to fully understand what it is that you will be building.

Who, what, why, when, and where?

Additionally, it will also include the consideration and the selection of the tools and materials that will be used to complete the solution. Why am I talking about all these different ideas and things that are done in the architecture of these amazing structures?

It is because software today is very similar. Software is very complex, but we still need to answer the same questions to understand how the solution will solve the problem. Our teams need more or better analysis and design "aspects" added to the SDLC - Agile Scrum/Kan Ban doesn't disallow these exercises/tasks. However, the guidance on when to do analysis/design, who is involved, and what are the assets/artifacts from these meetings is not very clear. This is because there should be different disciplines involved, perhaps at different times. None the less, we need to figure this out. You shouldn't have to ask for permission to do analysis and design work for a feature - just like you shouldn't need permission to write unit tests for your code. You just do it because it is the right to do.

In my opinion, you should not be able to create a user story unless there were analysis and design performed for the feature by the different disciplines? No Mockup-Driven-Development allowed here.

Let's Build Now Mentality

There seems to be this unspoken desire to start development as soon as possible. Even before you fully understand what it is that you are building. It is interesting to me that we can spend thousands to millions of dollars on software projects that fully do not solve the problem. This is because no one stopped to do proper analysis and design before they started writing code.

When did this start to be the normal process of developing software? Nowhere else in our lives or non-programming lives do we do this. When we embark on some project or even a small project like organizing a picnic or a barbecue on a Sunday afternoon. We do some thought and planning. We know who’s going to be there and we know what kind of food we want to serve and what it is going to take to execute and deliver that Sunday afternoon so that everyone enjoys it.

We normally do these things in our every day lives. However when it comes to software development for some reason we throw common sense out the window. We think things just happen. I’ve heard some teams say that they use an emerging architecture approach. That means they don’t have one and whatever happens is the architecture. This is horrible! This is not architecture and it certainly does not include much design, effort, or thinking.

I think some people do more planning for an afternoon barbecue than they do for multi-million dollar software projects. You are asked to build something from scratch, something new, something that’s never been done before and you need to figure it out. What are you going to do?

But also important, what tools and materials are you going to use?

I Want Shiny and New - The Latest and the Greatest

Who doesn't want to use the coolest new toys on the market? Who doesn't like shiny and new? For many things this is OK or even desired. For enterprise application though, you need to take a step back and a deep breath.

Shiny and new is not always your best option. Just saying.

The selection of tools and materials is almost as important as figuring out the what, who, why, when and where of something. This is because it will impact the execution of your solution. And it will also determine how your users will work with the solution. And it also has a huge impact on how long your solution will last. Think about some of the structures that have been built over mankind‘s history. The things that are still around are made of materials that last. Or, they are structures that are well-maintained over a long period of time. This means that someone knows how to maintain and take care of the solution long after it has been built and released for general use.

One thing to consider when you’re selecting your tools and materials is to determine what the community or worldwide support is for these tools. Say for example this is a new shiny new web framework. Does this framework have the backing of a large company? Is it supported? Does it have great documentation so that your developers will understand how to use it properly? Are there good or great reference examples of using this framework? Are there conferences or online tutorials, or training courses, or books that show or demonstrate the capabilities? Is it supported by the community?

Are there meet ups? Are there local or international conferences that include the application framework or tools?

The reason why I’m asking all of these questions is that you need to have tools and materials that are well received, respected and supported by the community. This means that there will be resources to build out your solution and/or maintain it in the long term future.

Foundation

You really need a strong foundation. Recently, I was fortunate enough to travel to France and to see the Eiffel tower. The structure of the Eiffel tower is amazing. But one of the first things that you really notice when you get up close to the Eiffel tower is it foundation. The four corners of the footings are huge and massive and they’re made out of material that looks like stone and it’s going to last and it doesn’t move.

It is the same with any technical solution. You need to have a strong foundation. This means that you have to have some planning so you know what your foundation is. You need to have an architecture - one that fits the solution that you’re going to build and one that can be executed by your developers. If you choose materials and tools as well as an architecture that no one has experience with then you will not have a successful outcome. You might get close but it’s not gonna be of the quality that you need or want.

More information about Angular Architecture at https://www.AngularArchitecture.com:

• book
• guides
• podcast
• blog

Therefore the selection of your tools and materials also has to consider the resources or the people who will be building the solution. These are the developers, the software engineers, the Devops individuals, and the database administrators, all of these individuals will have to have some experience or capability to learn how to use the tools and materials effectively and efficiently.

You can’t just pick the best materials or the best tools; as well as the best architecture and hope that you’re going to have a great product. It really is the people. The people your developers are the ones that will build and execute on the design of your solution. Your people are the most important aspect of any software project. As people, software engineers or developers we tend to get very excited at the very beginning of a project. We are very anxious to deliver and to show how good we are and that you chose the right people to do this job.

Process Over People

Does anyone remember software development before all of these product owners, scrum masters, project managers, delivery managers, or other stakeholders got so involved in the software process?

Software development today seems like it is approached with a factory-like mentality. Developers are just these workers that put pieces together. Developers create software like it is an assembly line of a auto factory?

What in the world does assembly line manufacturing (SCRUM) have to do with software?

What do I mean by this? They approach software is if we are building widgets in a factory. It is really that simple, isn't it? That it is so easy to monitor the production and the time it takes to build software parts and pieces; and assemble them into a set of working features. They want to be able to estimate how much time it will take to build components or features. They want to plan and estimate continuously. They want to create pretty reports so that they can deliver these to stakeholders or investors to show that, “We we are on time!”. All of this, with the expectation that we will deliver on time even with all of these interruptions and focus on process over people. it is ridiculous!

I cannot imagine that the builders of the pyramids had Kan Ban boards or scrum masters. Or that they had sprint planning meetings and planning poker! I'm not against good process - just process over people. And by people, I mean developers. Developers are the ones executing work and delivering the product. Everyone else is just support - some of them only checking off boxes on a large todo list.

Here is an example.

In Real Life...

On a recent project, we are charged with building out a new platform of new products and services for the company. This is the beginning of a total rewrite of a suite of applications that the company has acquired or developed over the last 10 years.

Currently, there has been about 15 months of development on this project. We have had at least four different scrum masters. We have had four different architectural direction changes. We have also had three changes in VP-Level management of the project and technical leadership.

I was able to set up the development environment, the infrastructure of the application, and also the architecture that would be used to implement each of the features. All of this was in place before we started working on the first feature. Would this be enough though?

However, the focus was on building the shiny features that would impress our investment stakeholders. These features had other dependencies. Why is this a problem? Well it means that we cannot fully create this feature without the other dependencies. We would have to come back to this feature and refactor so that it works when these other features are put into place later.

Do we do this in real life? Do we completely remodel a kitchen in our home? And then afterwards decide that it would be a good idea to now add plumbing and running water?

Why is this a problem? Well 15 months later we just finished implementing security for this application. We now have roles and permissions that we can use in these features. However, roles and permissions are an integral part of the entire application's feature set. Therefore it should’ve been the first feature that we worked on. This feature is not as shiny and cool though. Agile Scrum is based on the auto industry manufacturing mentality - would they build cars without engines and then decide to put the engine in after the paint job? I wonder what they do?

The amount of rework as well as the amount of time to have discussions of re-factoring features that should’ve been built correctly in the first place is inexcusable.

The main reason why we worked on these other features was to show stakeholders and investors that we could actually build out the new features on the new platform. They scheduled regular meetings to showcase these features to the stakeholders and investors.

So I guess building application features without the proper foundation is OK in this new modern way of developing applications? Yes of course there is a business aspect to software development. However, what is happening is that we are putting the wrong things in a higher priority than actually building working software.

Evidently, working software and our people is a lower priority than providing a smoke and mirror progress meeting to stakeholders and investors. This is a "dog and pony show" for our product team. It gives valuable insight to their stakeholders that the product team is delivering on their commitment and promise. Really?

I remember years ago using agile methodologies, developers would demonstrate or show actual working software to our stakeholders. This would be software that we wouldn’t have to go back to and refactor to make it work when the other features were implemented. Please do not confuse this with integration tasks. This is absolutely a doing the implementation of features in the wrong order or sequence problem.

I did mention that the software dependencies should be developed and implemented in a specific sequence. If you follow this approach, you will find that the dependency that you require will be there and the implementation of the next feature will be much easier. I think this is common sense. However, I wonder why we still were not able to build the features in the correct sequence. I have heard the excuse, “We will do better next time.”

The product team really is serving their master: the stakeholders and investors. And, from a business standpoint this makes total sense to me. However the product team should not dictate from a technology standpoint how software should be delivered and executed. The product team should be able to define who is going to use the product? When will they use it? Where will the product be used? What are the absolute required features for the product? Why is this product needed and what purpose will it serve? In our process over people and factory widget development mentality, the product team thinks that they are an effective part of the SDLC process. During this project the product team could not accurately estimate when features or larger milestones would be complete. This was due to the fact that many of the features were missing required parts and pieces. Instead, they asked for sizing of stories and team velocity calculations. However, this would not be helpful because the current set of stories were incomplete and lacked many details. Therefore the estimates could not be accurate.

The scrum masters on the project were somewhat pleased that they had a set of stories to put into a sprint. However, how would they know that the stories were complete and had enough detail to be executed. Therefore, when sprints completed and many stories were not done there was panic and concern. Now we are trying to figure out why the sprint failed? Why could we not complete all of the story points in our sprint? Obviously, the developers are not working hard enough, right?

How About More Process Here?

Well, maybe the answer is that we need more Sprint grooming and planning. If we do this our Sprint will be successful, right? Grooming stories that are incomplete and lack detail is a very time-consuming and tedious process. Sometimes, we would have up to 20 or 25 people in these sprint grooming meetings. Most of the people there did not participate or comment during these discussions. Think of the man hours of money that just goes down the drain when you have this many people in a meeting not really doing anything.

Imagine a world, where the right people at the right time could sit down and talk through these features and determine the requirements to make it happen? We could actually create a story or a set of stories that represents the work to be executed. Instead we get a single, vague story with a pretty picture along with a lot of assumptions.

The solution here is to have the right people collaborate and do enough analysis and design required to understand the problem and to create the stories to execute work. This should be part of any team's SDLC process or workflow. However after 15 months, it is still impossible to get this type of meeting scheduled or the right people talking to each other. What you get is a few team members and a lot less man hours required to create the stories. This is way more efficient. Now if you do a Sprint grooming on a set of stories the work will be minimal and there will be no time wasted.

But We Are Doing Analysis and "Design", Aren't We?

Mockup-Driven-Development creates more chaos than solutions.

On this project specifically, the product team also goes beyond their scope of work. They also engage and interact with a UI/UX team to create mockups. Typically, mockups are part of the analysis and design phase of a project. However, they do these exercises and have discussions without including the different disciplines from our technology team. What do I mean by this? Well, if you had software architects, engineers, quality assurance engineers, database or data analysts involved, we would be able to provide different points of view during these discussions. Interestingly, the UI/UX developers would have a more complete picture (i.e., data, business rules, validations, messages, notifications, workflows, etc.) to base their UI/UX designs and mockups on. Wouldn't that be wonderful? The requirements would be much more detailed for the developers to execute.

UI mockups is just one artifact from a single discipline that is part of a set of artifacts from many disciplines in a collaborative SDLC process. Where does Agile or this process-over-people mentality address these meetings for analysis and design? There is not story or card to apply time to it - so it must not exist or be valuable. Do we think that the designs and workflows to manufacture an automobile just happened because some product owner had an idea?

Instead, we get user stories with, ”…as a user, I would like to blank, so that I can blank.” These user stories include a pretty picture of the UI mock-up that is associated with the story. In the beginning the product team thought that this was enough to build software! The stories were not organized or grouped nor categorized. The stories lacked relevant detail for the developers. The stories were not in a specific sequence, nor did they indicate any of the dependencies that were required. The stories did not include business rules or data requirements. If the user story included a web form, there were no details on the form validation requirements. There was no discussion about backend APIs to support the feature. There is no information about even if the data existed or was available or if we had the correct data objects that we could actually use in our backend.

I wonder if there is a magical data fairy that came out at night and sprinkled magic data dust on the story to make it happen.

If you are wondering why this team could not just have simple discussions for these details in advance you’re asking the right question. It was brought up many times. There were samples of stories that included the correct information. However, the product team decided that they could do all of the analysis and design by themselves; and they made an attempt to provide this level of detail. However, they still did not include the different disciplines from across the development team. This is the problem. You need to have representation from each of the disciplines on your development team. There’s no way that a product owner/team can know or understand the technical details and technical requirements for technical execution.

A team will always know more and have more capabilities than a single team member or small subset of a team.

And therefore it was completely unacceptable for the product team to expect that our developers could actually execute and deliver the stories that they put into this backlog. They thought they did an excellent job. They thought they provided all of the necessary information that we would need to build out such a new platform. However, software is much more complex especially in this modern world. Our company has different disciplines within our technology team. We have the correct and right people to be involved in these preliminary discussions. In these discussions, we can go through different exercises or collaborative discussions to add detail and color to the requirements or features under consideration. We can also, at this time, help them to prioritize work items so that the correct things are done first. Then we eliminate the dependencies of the features by doing them in a correct and proper order.

It is as if software development has turned into a drive-through experience. That we can just pull up to some speaker and make an order for a cheeseburger, no pickle and a medium french fry. And just pull up and get a bag of software with exactly everything we ordered. It is as if there is an army of software engineers and technical individuals behind the scenes creating the software based on the ticket or order from a drive-through. The expectation from the product team is that we deliver exactly what the pretty picture looks like, however without the proper tools and details it would be impossible to deliver this feature and also do it in a timely manner.

Please pull up to spot #1, and we will bring your software out to you when it is ready!

Build Something Now, Or Else...

Sometimes software engineers are overachievers and they might over promise and many times under deliver. However I think it’s best to keep a balanced view over the amount of completed work that is expected. Especially when the project or solution is brand new and no one has ever built a solution like this before. The entire team should focus on the milestones of the project - not the individual battles (i.e., Sprints). Battles are lost at times, but become important to the overall success of the solution. I'm not comparing software development to war - just a comparison to keep the perspective real.

Developers do not need Scrum Masters or Product Owners going ballistic when all of the stories didn't get finished within a Sprint. It's a sprint - it is not putting a screw or bolt on something in a factory production line. If it was so easy, there wouldn't be a shortage of developer resources.

Software is more difficult than that, isn't it.

Some people feel that greenfield projects are difficult. This is because there is nothing like it nor a reference that can be used to guide the implementation or development of a very unique brand new solution. Personally, I prefer starting a new project without defects or technical debt, it just feels good.

Sometimes what you need though are experienced developers, perhaps some who have worked in many different disciplines or different domains. And they will recognize and see things that are familiar to them or similar to some other aspect or part of something they’ve developed before. This is where their intuition and their experience can really pay dividends. They will quickly understand new concepts and figure out how these things will fit in work together.

It is essential to start with your technical leadership team first. You need to have strong technical leadership that includes solution architecture and software application architecture. These are individuals that have the years of experience to guide and direct a team. They will also can foresee problems or issues with certain aspects of a project. Rely on these individuals heavily because they have seen many things and some of them have even forgot more than some other developers even know at that point in their career. Their intuition and their opinions really matter. So pay attention!

You also need to plan the execution of the work. The sequence and order of things to be built make a difference. So it is not enough to define the stories and what the requirements are. You have to know and understand how they work together and in what order and sequence you need to implement them. Plan the execution. On this topic, product owners provide valuable information for our user stories. However it is a developer that will use the information in the story to execute the work. Therefore, it is essential that the story includes technical details. The technical details can only come from technical disciplines within your team. Therefore you need to have someone involved in the technical aspects of a user story. There may be several user stories that target different technical disciplines or expertise. These also need to be detailed out so that the developer knows exactly what is required. This is not telling them how to do it. It is giving them the correct information so that they can execute the story and deliver the expected result. Sometimes a developer will need to create a proof of concept or have a spike story that enables them to fully understand the problem and the different solutions available for the problem.

Conclusion

Sometimes you need to slow down to go faster. Take the necessary time to understand the problem. Plan your execution. Take time to select your tools and materials. Work with your product teams to create an effective SDLC workflow. Communicate. Collaborate. Make the people the most important development assets - not the process. Processes come and go over the years. We all want to enjoy our work as software developers - it should be fun.

Do the right things, at the right time, with the right people, for the right people.