The developer of our website told us: "This can't be done! You should have told me before!" when we asked to change the number and the content of some of the tables of our site.

In this challenge, Francesco Cirllo will work on the original typescript front-end code delivered by that Senior Web Developer and will show he make those web tables ready to accept any request by applying an adaptive design process able to reduce the cost of change of software development. (And of course without applying the "IF Strategy.")

Here you can find the next session of this series of workshops:

About this Software Development Challenge

The Typescript Web Tables Challenge is a real case in the process of developing our web.

The number of courses we offer is increasing and more trainers will soon be teaching the Pomodoro courses. Our customers want to have access to up-to-date information on course dates, access to resources related to our courses, etc..

To do this, we decided to renew our website not only aesthetically but also in terms of information management. For the first time we decided to develop a real front-end (typescript) and a real back-end (Java).

This is the business opportunity: making the information on our courses dynamic allows our customers to get the information they are looking for clear and up-to-date, and us to reduce the effort to update it.

There is one element where all this - aesthetics and information - comes together. Tables like this one:

This table is dynamic, the information is not written statically in HTML but is retrieved from a DB, is validated, a certain format is applied to certain values following defined rules, and a layout is dynamically assigned.

Our challenge was born one day in March when working with the Web Developer through Zoom, I made an innocent request:

The combination of these two answers takes me back to the 90s for a moment. When software developers could incinerate any request for change with a purely technocratic response. Then images of the next 30 years flash through my mind: the first refactoring browser, my first TDD code, emergent design and incremental evolutionary processes and...

This dynamics happens on a daily basis in many teams. The answer can be conjugated in various ways:

• "It can't be done!"
• "I can't estimate how long it will take"
• "It would be better to rewrite everything than change the code now."
• "Are you really really sure you want to do this? It is not bad now after all..."

We're talking about today's teams. Teams that are dead set against Waterfall, and yet... so many developers continue to give technocratic answers that actually stem from the low quality of their design decisions.

My Web Developer is a successful professional in the field. I've been working with him for years. It's like he's part of my team. We trust each other.

I received the zip file with the typescript workspace right away.

We started working on it together. We had fun. We removed classes, created new ones, and injected objects and patterns:

"This could become an interesting Challenge."

And here we are!

What are the objectives of this Challenge?

The main objective of this Challenge is obviously to "free" Web Tables to go in any direction the business requires. This Challenge is all about front-end development. In particular, we will be injecting the typescript solution into a Shopify store that we actually use only as a website through a brilliant idea of our Web Developer.

As a Customer, I'm sure I don't know all the possible evolutions of the Web Tables and as a Software Designer, my evolutionary strategy is to reduce the complexity of my design solution, to keep it open without having to anticipate future requests.

What are we going to do in the various episodes?

We're going to extract the code from the zip file that was emailed to me by my Web Developer and we're going to analyse it. We will try to understand why it's been written that way. What consequent limits that design solution has from the point of view of growth and evolution.

And then, I will show how, working together with my Web Developer, we have made adaptable several different aspects of our Web Tables:

• The construction of the table (=with/without Caption? Titles?)
• The styles (=adding and removing them to different elements)
• The definition of a layout (=how many columns and which info in which columns we want to show)
• The acquisition of data (=from database or json files or in memory, etc.)
• The information validation process (=are links valid, are sessions ready to be sold)
• The assignment of particular formats (=euros need zero or two decimal places, dates needs different formats depending on the case)

Let's get to the fun part:

1. We will not use the "IF Strategy" - of course...
2. We will not write HTML code - It is boring to write HTML code. Isn't it? Instead, we will try to use DOM objects to compose our tables. Or at least we will try!
3. We will not use a Front-End Framework (ie React, Angular, etc.) - WebPack will be enough. I don't want to depend on a framework.

Ready to work together?

—Francesco Cirillo

Who is it for?

Ideal for Software Developers and Technical Coaches.

Episodes

About the Trainer

Upcoming Sessions

Here you can find the next sessions of this series:

Can't make it on any of our dates?

We can discuss other options with you

Testimonials

Useful Resources