Archive for category Software Development
Here’s the talk’s description:
Most developers hear about “Red->Green->Refactor” as part of the TDD process. Some never get to the “refactor” part. Some only refactor the “production” code, but not the test code, after all, that’s “just test code”. Tests become cluttered, hard to maintain, and are abandoned.
After a short hiatus, the Improving Code user group is back. The first talk of the year happens online next week, Feb 3, 6:30pm CDT. RSVP here, will ya?
Refactoring Test Code
Every developer hears about the TDD process as “Red->Green->Refactor”. Some never get to the “refactor” part. Some only refactor the “production” code, but not the test code, after all, that’s “just test code”. Tests become cluttered, hard to maintain, and are abandoned.
I have mentioned about the importance of technical communities for me. This month, I take a moment to reflect upon something I was doing related to communities 20 years ago: in January of 2001, the first issue of RapoZine was released!
Still living in Brazil at the time and participating in a community that craved for content in Portuguese for Visual FoxPro, I got together with two other members of the community to put out this little magazine. Leandro W. and I would each write half of the content, and Nilton P. would take care of the website where people could subscribe.
We’d print out the pages at whichever company we were working at the time, and mail it out to the subscribers. Simple and easy. Nothing fancy needed. The community was craving for content! For that first issue, we also enjoyed an article contributed by Ellen W., from CoDe Magazine.
In its first year, we had about 120+ subscribers.
It was a ton of work to get monthly content written and put out like that. That’s how I got started on technical writing.
The name RapoZine was a combination of “Raposa” (Fox in Portuguese) and “magazine”.
When the printing and mailing costs got too high, we eventually alternated into a digital version. The articles were created in HTML, compiled into a password-protected EXE file, and a download link was sent to the subscribers. I need to dig up some old backup files… I may still find some of those issues here.
With my plans to move to the US in 2002, I didn’t have time to keep the magazine running. Fortunately, the main worldwide FoxPro community at the time, the Universal Thread, which also had their own electronic magazine, UTMag, approached me to join forces, and we merged UTMag/RapoZine for the community. The magazine became free for all, and published in three languags: English, Portuguese, and Spanish! The Universal Thread had a great system to allow translators to collaborate and get the content out. I continued as a co-editor and coordinator for the translation team. About a year later, the Univeral Thread acquired RapoZine, and I stepped away to pursue other goals.
I enjoy having some music playing while I work; even more so if I’m using the Pomodoro Technique. But I’m very specific about my work soundtrack!
If what I’m doing the requires deep thinking, I need instrumental music. Most often, that’d be classical music (Mozart, Beethoven, Vivaldi, Bach, Chopin, Paganini, are among my favorite), but it may also be World Music (Kitaro is my top favorite). For shallow thinking, I may go with guitar albums by Joe Satriani, Steve Vai, Steve Morse or maybe movie soundtracks.
When I already know what needs to be done (either because I’ve finished the deep thinking mentioned above or because the task is just busy-work), then I crave some high-energy music (usually heavy metal, but it could be some other things I have in my music library).
Here’s an example:
I’m about to implement a user story. I set two Pomodoro sessions: one session to read through the user story and acceptance criteria, review mockups, etc, and another session to write my specs for it (only the Given-When-Then statements). My soundtrack consists of classical music.
Now I’m ready to write the actual tests and just enough code to make them pass. The soundtrack may be some fierce heavy metal, as I blast keystrokes on the keyboard. As I do this, I may practice the “sing and read” speed reading techinique; as I sing my favorite songs, I read through my tests, write code, read what I wrote, and eventually read it again in preparation for some refactoring.
Do you have a soundtrack?
Challenge times bring us the opportunity to either reinvent ourselves or flex muscles that had been dormant. I’ve talked about the importance of technical communities in my life, how they help us improve our networking skills, how we can use our voice and reach out to others.
The year of 2020 has made us all push the envelope when working with our communities, either creating new ones or keeping existing one engaging to their members. While many of us miss the in-person communities, we have also been learning how to make the best out of online communities.
Tomorrow, Dec 18, I’ll be on a live virtual Lunch and Learn with my good friend, talking about our experiences Building Stronger Online Communities. Join us at 12pm Central Time! Click here to find more information about this FREE event and register.
This is the session description:
User groups are a great way for the community to get together to share, learn and network around specific common interests. This year saw us having to pivot to virtual-only events and uncovering both opportunities and challenges… How can we create great community experiences in a virtual world? In this Lunch and Learn, attendees will hear from two community leaders, Sarah Kim and Claudio Lassala, on how they’ve been growing their online communities and hosting virtual events.
Just a couple of weeks ago, I’ve blogged about The Importance of Technical Communities (the ideas really apply to any community in general, much like what I do with my motorcycle track riding community). In this post, I’ll focus on the networking side of getting involved with communities.
Every week, I share things on the Virtual Brown Bag; I may share an article or book I’ve read, a challenge I’m facing at work, a successful way I’ve found to implement something. Whatever the case might be, once I’ve shared it with the community, I’ve planted a seed in their minds: should they either run into the same challenges or solutions to it, they’ll think of me. They’ll know who to either ask questions or offer help to, or make connections (“Hey, Claudio, last week you mentioned you were having issues with Cypress. I mentioned it to a co-worker and he has the solution. He’ll be reaching out to you!”).
I’ve talked about similar things when I shared my thoughts on “fake until you make/become it”. We don’t need to figure it all out by ourselves. We don’t need to fake it. Others will help, but we need to either ask for their help or let them know that they could possibly help us.
Every month, I update my “Now page”; that’s an easy way for people to know what I’m up to. A few months ago, I mentioned I was starting to work with Angular. Less than half an hour after I’ve posted it, an old co-worker who I hadn’t talked to for a few years reached out to say he’s done a lot of work with Angular and I should keep him in mind if I had any questions. We also took the chance to catch up with life in general.
Last week, I’ve read Derek Sivers’ writing on how you can take a situation that may not be ideal and flip it in your favor. He touches on “it’s all who you know”, and got me thinking about how my professional career started; I walked to my whiteboard and sketched out my career map up to today, calling out every single person somehow responsible to pivotal moments. How did I meet them? How have they helped? Have I been keeping in touch with them? Have I expressed my gratitude to them?
A good book I’ve read on the subjet of networking is The Power of Who.
Our communities and networks can (and should) be connected. People in my technical communities are aware of my involvement with motorcycle track riders; those riders are aware of my involvement with software development. They are all aware of my activities as a musician. These are all opportunities to connect with people, expand my network, offer help, get help, improve, grow.
Front-End development technologies come and go. In my experience, they have been the single most volatile part of software. Their lifespan seems to be very short (5-10 years).
Why are they so volatile?
- Probably because the devices the users interact with evolve far faster than what they don’t interact with (back-end, databases and such);
- Users now expect more. Back in the day, users would happily use whatever software they had to automate their work. That has changed over the years as most people have their own personal computers and devices, which they use for way more things than just “boring accounting and payroll systems”. Also, since the first iPhone came out, users have learned to expect software to be more intuitive. And now “there’s an app for everything”, and for each app, there are likely multiple options to choose from.
Since the late ’90s, I’ve worked on a huge number of software “rewrites”. Most of them were really painful and time-consuming. Why so?
- Developers put way too much code on the front-end;
- In most “rewrites”, people simply want to replace the old with the new, making the new one look and behave like the old one, but on a different platform
Every time a new front-end toy comes out, I’m mostly interested in seeing how developers are writing code in it. More often than not, I see the same pattern over and over: a TON of code put right there in the front-end. Knowing that these frameworks and libraries aren’t like to last more than 5-10 years (by last I mean to be continuous developed), I know that a rewrite for such software means, well, rewriting all of that code!!
For the most part, the front-end part of software should simply allow the user to ask questions to the system and see responses. That’s it. Present the users with what they need to formulate questions, and then show them the answers in the best way possible (which could mean, fast, or illustrated with charts, or whatever it takes to give users the insight they need in that moment of time). In certain scenarios, it may be crytical to have most of the processing happening on the front-end, but those are the exception, not the rule.
Don’t get me wrong: I used to jump at every new shiny toy, too. There was a time when Microsoft put out a new toy called LightSwitch. That was probably the first time I looked at a new toy and thought “hmm, I don’t think that thing will last long”.
I didn’t quite recall when it went away, but found out on a quick search that its lifecycle started on Oct 30, 2011, and it’s mainstream support ended on Jan 1, 2017. The official death announcement states that “the landscape has changed significantly from the time when we first thought about LightSwitch”.
Such a shame. I had worked so hard on adding LightSwitch to my resume. I had even documented my proficiency with it on this short 45-second video!
Technical Communities may be the single most important factor I’ve had (and continue to have) in building my professional career. Yes, that’s how important I believe they are.
I first got involved with communities back in the late ’90s. I got a job where I got to work with FoxPro, which I knew nothing about other than that it looked similar to what I knew at the time: Clipper and dBase. That was also around the time the internet was becoming a thing in Brazil in the days of dial-up connections.
In order to get up and running on the required tech stack, I found online forums in Portuguese.
There were many resources in English for FoxPro, but not a lot in Portuguese. I knew some English at the time. Many Brazilian developers didn’t. So here’s what I did: I’d see people’s questions in the online forums, look up the answers in English on the web, and reply to the posts in Portuguese. Why did I get from doing that?
- I learned a lot of FoxPro in a short period of time
- I learned a lot of English
- I helped other fellow developers
A member of the community invited me for lunch one day and gave me a couple of FoxPro books. I asked the reason for the gift, and he said: “If I help 100 people, maybe one of them will give me a hand in a moment when I could really use some help”. I have taken that lesson to heart and applied it to my life deliberately ever since.
Because I was answering so many questions, people thought I was an expert.
When a new version of FoxPro was about to come out, members of the community reached out to the Microsoft office in Sao Paulo to ask if there was going to be an official launch event. The MS manager said they could do that, but there were no MS employees in Brazil who were well-versed in FoxPro. The community member said, “well, problem solved: I know a guy”. Next thing I know, I’m presenting two full-day, soldout launch events. Attendance included people flying from other states (if you don’t know how big Brazil is, please pick up a map…)!
So that’s how I broke into technical public speaking. Next, I got into writing articles, creating a magazine, organizing conferences in a few different States, organizing study groups, creating training videos…
So much came out of the common need to learn a new tech stack, followed by the simple action of helping others along the way, with however little I knew of anything.
The fact that I’ve been living in the US since 2002 is directly related to this involvement with technical communities.
See why I have a cute fox as part of my office decor? Never forget where you come from!
Also, when some youngsters make smartass comments about the mention of FoxPro on my business card, I may just say: “sit down, kid, let me tell you a story…” 😉
Three years ago I decided to try out Xamarin. Given my experience with C# and WPF/Xaml, it seemed to make sense. I spent about 4 hours following some tutorial online and got the sample application up and running. Two months later, I tried to pick it back up: I launched the idea, hit “run”, and got some compilation error that didn’t tell me a whole log. After a lot of digging around on the web, I found out I had to update Xcode. After I did, the error in Visual Studio for Mac went away. Other priorities made me put that all aside for a while.
Last weekend, I gave in and decided to pick it up again. I have an idea for a mobile app that would help me with one of my hobbies and thought Xamarin would be the quickest way for me to get it done. The first feature for the app is a simple to-do list. That’s just a step away from the typical Hello World app, isn’t it?
After 6 hours of struggling, I gave up.
I was trying to use JetBrains Rider as the IDE. I thought of creating a Xamarin.Forms app, as it seemed the easiest way to have my app available both to iPhone and Android devices. I didn’t get passed creating the project, as it kept telling me that the “Android SDK is not installed”, even after installing all the Android things I’ve found out about; things that ate up 20Gb of my disk space, and I still couldn’t create the project.
I then decided to only target iOS: maybe if I at least got the app on my iPhone I’d find motivation to figure the Android deal later.
The project got created and I just tried to run it in the iPhone emulator (I didn’t write any code or change anything). Found some references online about Xcode, made sure to update it, but still, no luck.
Then, I tried to deploy it to my iPhone. First got errors about the Apple certificate needed. My Apple Dev membership expired years ago, so I renewed it ($107!). Got the certificate, then started getting errors about “Provisioning Profile”. Got it created, did what I told to do, as per online resources, and moved on to the next error: [MSB6006] “dsymutil” exited with code 1.
After some research on the error and not liking the answers I’ve found, I gave up. Six hours had gone by and I couldn’t successfully create and run a brand new project.
I’ll be trying Flutter next. Let’s see how that goes…
Notice the title doesn’t say Scrum “Software” Projects, because I believe Scrum can be applied to many different types of projects. Having music and motorcycle riding as the other passions of mine, I find myself drawing comparisons and reapplying learnings where I see fit.
In a talk about building trust through delivering results in Scrum software projects, analogies with hitting the apex at a race track have come up, and I felt I had to expand on that idea. So for this post, I’ll consider a software project, but again, the ideas can be applied to many types of scrum projects.
I’ve only started learning about apices and race lines when I started riding a motorcycle at a race track in 2017, so my comparisons here come from my understanding on the subject as of November of 2020. As I learn more, I may need to update this post in the future.
If you’re a fan of races (motorcycles or cars, it doesn’t matter), you are most likely aware that racers know how to hit an apex consistently and why they should hit them.
Consistency is key; hitting the apex consistently, lap after lap is extremely important. Hitting the top speed on a straightway isn’t as important as hitting consistently high average speeds, which yield fast lap times.
Reaching 200mph on the straight and then running off track isn’t the most efficient way to turn fast laps (not to mention you might crash when you run off). Working crazy hours during a Sprint to deliver a high number of story points isn’t an effective way to turn good quality software and keep doing it lap after lap; I mean, sprint after sprint (not to mention you may crash; I mean, get burned out).
The apex is typically the slowest part of a corner. The soonest you can get to WOT (wide open throttle, which means you’re using the vehicle’s fullest acceleration potential), the faster you can get to the next corner. But then, you also need to know that you will have to slow down in order to make that next corner. If you’re looking down to the speedometer to keep marvelling at how fast you’re going, chances are that you will be running off track. If we keep solely looking at number of story points, we may lose track of where we’re going.
In order to find the proper race line, with the respective apex for each turn, we need to analyze each turn backwards. We need to know what comes after each turn to be able to plan a strategy for getting in and out of the corner as fast as possible; if turn 2 is a slow hairpin, then we may never get to WOT coming out of turn 1. If turn 4 preceeds a long straightway, then we need to make sure we exit that corner as fast as we can, getting to WOT as soon as possible.
However, opening the throttle too soon, may cause us to run wide, creating a need to slow down, before accelerating to the full potential (a process that causes loss of precious time).
In a motorcycle, if we open the throttle too much too soon, it may cause loss of traction. Depending on how we handle the situation, when the bike regains traction, it may send us on a trip to the moon and back. Not pretty. How do I see that in a scrum project? Maybe we’re forcing performance optimizations when it’s not the right moment?
Back to planning the corner backwards: we need to see what’s coming. We need to have a vision. We plan for it. Then we execute it (by riding laps). As we do, we look ahead, through the corner.
We may misjudge how much speed we can take into a corner and brake too much. Next time around, we brake a little less.
We may not have good reference points (brake points, turn in points, apex, exit points) around the track to help us assess our speed and strategies. On every lap, we stay aware of those things, so we can fix it next time. Remember sprint retrospective meetings?
Such approach can only work if we are not going recklessly around the track. If we’re riding without control, we will not be able to evaluate our execution; we won’t learn anything from it. So we can’t improve it. We can’t come up with better strategies.
Only hitting the apex isn’t enough. Racers have different strategies for hitting the apex. If they’re trying to make a pass, they may decide to take an early apex, so they can carry more speed into the corner, hopefully passing the other rider, but at the expense of coming out ot the corner slower.
On the hand, if they’re trying to turn consistently fast laps, they may take a late apex, where they carry less spead into the corner, but are better placed to accelerate harder out of it.
See the riders in the photo below: some are trying to pass, some are planning to pass, some are trying to avoid being passed. Their plan to hit the apex varies based on their desired next result (turn a faster lap to stay ahead of the others, get closer to the rider in front and set up for a pass, etc.)
Each lap is a sprint. One fast lap does not guarantee a race win.
Each race is a release. One race win doesn’t guarantee a championship win.
Consistency is key.
Vision, plans, execution, evaluation, tweaks, repetition, strategies, using them accordingly, focus, flow. Wait, am I describe racing or a scrum project?
Image source: Pixabay