Categories
Software development

Two observations on software engineering

Reading Time: 3 minutes

For a guy with a hammer, everything is a nail

Use SQL for everything

At Mastercard, I used to have a colleague who is great at SQL. And once I realized he used PL/SQL for quite complex business logic for a “promotion build” and it backfired. The customer noticed there were some inconsistencies and notified us. Upon further examination from yours truly, it appears the code has some logic flaw. Note the flaws in the PL/SQL is hard to detect, compared to code/app written in a more general purpose programming language such as Java and following proper testing procedure. The cost of that mistake is we end up sent about $40 k to the business customer (a bank). I can understand why PL/SQL is being used there, because that’s the main skill my former colleague had, and in other words, he has this hammer (SQL), and he was using it at every place possible. A second reason is my manager was probably under pressure to deliver that functionality, and he probably was not willing to or getting help from the dev team: and I knew we have quite a few Java developers there, and some of them are pretty good.

Performance Testing went too far

This applies to performance testing (JMeter is a popular tool). When I worked at Ascension, my boss likes running performance testing via JMeter. Also at the time, we have an engineer who knows the tool. And once we ran performance testing without realizing that we sent emails in our testing, and our testing brought the company outlook server down to its knees 🙁 In hindsight, I felt this kind of testing is not really necessary. You can read some of the examples I listed in my blog post too. The lesson here again is: someone fell in love with the performance testing, or performance of the system. I am not saying it’s a bad thing, but the approach they were taking to me is very amateurish. And as you can read from my blog post, that’s one main factor a multi millions dollars project failed. Somehow the recent DOGE efforts in finding fraud and waste in the US government reminded me of that failed project.

Layoff to cut cost

Now Elon’s DOGE team seems got obsessed with cutting staff (hammer) in the federal government: which was first used during the Elon’s Twitter takeover. He is using that hammer again from his previous experience. In short term, if you cut staff, you may get some more productivity from the remaining staff, because the remaining people will be scared and have to work harder to make up the slack etc. But there will be longer term consequence. I don’t think it’s as straightforward as cutting staff at Twitter (X). But again Elon only knows hammer. He really doesn’t have other tools in his toolbox.

I am pretty sure this “hammer/nail” mentality applies to other fields as well. For example I saw quite a few Asian parents pushing kids to work harder (the main reason is those Asian parents mostly worked hard to get here), without realizing “work smarter” is actually way more important.

How to measure the productivity of software engineers

My short answer is you cannot. But for managers they cannot take this answer, especially at the places they have mandatory quota based layoffs, in America I recall Jack Welch is the one who started it: refer to Jack Welch: how he justified his famous ‘fire the bottom 10%” and Short-term profits and long-term consequences — did Jack Welch break capitalism?

And at Mastercard, in early 2019, yours truly was hit by that too. I was Lead Software Engineer at the team, but unfortunately I got into some “grunt” work, not necessarily code related, thus my GitHub stats was not great.

What are the grunt work? You may ask. And since you ask me: I would ask google. Here are the answers from Google’s Search Labs | AI Overview

======

“Grunt work” in software development refers to the repetitive, often tedious, and basic tasks that are necessary to complete a project, like data entry, basic code cleaning, configuration management, or setting up initial infrastructure, essentially the foundational work that needs to be done before moving on to more complex features or design elements. Key points about “grunt work”:

Example of grunt work in software development:

======

So my lesson learned from there, along with a similar lesson I learned from Ascension Health, is: coding more, and do less of the grunt work.

At least, when a manager who only cares about those stats come by (aka, someone like Elon Musk), I can point to the source code repository, and show her/him the stats.

In reality though, layoff is more than just the stats.

PS: came across this YT video – Aging Software Dev – Can You Still Compete After 40?

Categories
iPhone app

Software engineering 101 for iOS app development: I

Reading Time: 2 minutesI thought this for a while, when I was in the Voices That Matter iPhone developers conference, I have seen the great interest from iPhone app developers, from indie developers (individual or small team development shop), to high school teacher who taught self programming and teaches kids on iPhone programming. They come from different background, software consulting, development, education, authors. Being from enterprise software development background and have created iPhone app on my own time, I think I can share some of my thoughts on “applying software engineering principle to iPhone app development”. Hopefully this can shed lights on the best practice of iPhone app development, and ideally those thoughts can be applied to software development on other areas as well.

The No. 1 thing I want to talk is testing. Why we need to test an iOS app?

As my old C++ professor said in the class: a program is a novel if it does not run as expected. We always want to test the software (aka app) if it’s a bit complicated and takes some time to develop. For simple iOS app sometimes we would just skip the formal testing process, and in some cases we just assume it works. I learned the lessons the hard way recently.

1) After I uploaded the binary via iTunesConnect, I found some problems with the app. So I rejected the app, fixed the problem, and uploaded it again. I did this 3 or 4 times in one case. After the last upload, my app was end up in “Upload received” status but did not automatically move into “Wait for review”. Waited anxiously for a few days. Finally I googled and found this article on StackOverflow and followed the instruction to contact Apple, waited for a few more days, and it got resolved eventually. Had I tested the app more thoroughly, I would not have to go through all the pain and the app would get reviewed soon.

2) More recently, I added a feature to the app and tested it on iOS 3.1.2. After it being released, I tried it on iPhone 4, and I found the feature does not work. Ouch.

How to test?
Ideally we should have a test suite and automatic test. But we don’t live in an ideal world. As I minimum, I would test the following: