About this Software Development Challenge
Francesco's Software Development Challenges are journeys in which Francesco, you and the other participants will develop one or more features of a real application. Francesco will lead the development of the feature to be created and show you how he makes software design decisions, how he applies principles and tools, why he chooses one pattern over another and why he prefers certain practices in specific contexts.
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:
Francesco: "Only for the tables in the Catalogue section of the Learning Path pages... Could you (1) not display the "Area" column (it would be a useless repetition in the Tech Page to see the column Area always containing "Tech"), and (2) could you put the course description in a new column: 'Description?'"
Web Developer: "This can't be done! The description doesn't look bad under the title column..."
Francesco: "Come on, it's just a matter of removing one column and adding another"
Web Developer: "I have to develop a new type of table..."
Web Developer: "...You should have told me before!"
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...
Francesco: "But, if you were a customer of our courses... wouldn't you prefer to see that table organized the way I asked for?"
(After a moment of silence, the Zoom frame revealed the Web Developer nodding. I know I can trust him.)
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.
Francesco: "Would you show me your code?"
Web Developer: "Yes sure!"
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:
- We will not use the "IF Strategy" - of course...
- 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!
- 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?
Who is it for?
Ideal for Software Developers and Technical Coaches.