Tag: design

Don’t Ask Me about UI/UX

Readers with up-to-date Twitter skills will recognize the classic Willem Defoe meme.  I have been doing web apps for a long time, and it seems everybody is an expert in UI and UX – both!  They have, as Jamie puts it, a “flair” for web design.  Genius-level stuff, like green CTA buttons because green means go.

What will it look like? I don’t care.

On a recent gig, the first thing I did was replace hi-fi mockups with Balsamiq.  The product team had been killing themselves to do mocks in Figma, and failing, and then wrangling with the UI developers well into each sprint.  There’s a good reason why Balsamiq uses scratchy lines and a comic font, which the crew understood instantly.

Is this what it’s going to look like?  No!  What will it look like?  I don’t care!  Well, I do care, but I studiously avoid having an opinion about web design because I respect the professional competence of my UI/UX team.  I have a habit of saying “I don’t care,” when what I really mean is: I don’t want to interfere in a decision better made by actual experts.

We know exactly what the page will do, from business analysis and functional design.  We also know roughly what it will look like, from the style guide.  But, what will it look like, exactly?  I am content to wait and see, and BTW we’re agile and we’re AB testing – so it will change, anyway.

Brah, where’s your queuing service?

Everybody thinks they’re an expert because UI/UX is the presentation layer.  It’s (seemingly) just visual.  People think, hey, my socks match my pants, so I can play too.  Oddly, no one ever offers advice on how to do the data layer, or what message bus to use.

Software Development at RumbleOn

I have some jobs open right now and I am also busily documenting our Software Development process for the auditors, so I thought this might make a good blog post.

The magic starts in our Product Management department.  We treat all our software as program products with roadmaps, features, and release plans.  This includes our internal operational systems as well as omnichannel retail.  I have long been a proponent of this approach, even for APIs.

Our vision is to have an integrated pipeline from the survey portal all the way to deployment.

Artifacts like requirements, concurrence, priorities, and customer feedback are maintained in Aha! Roadmaps.  Product Management is also design driven, but I digress.  This post is supposed to be about Software Development.

Software Development includes four agile teams.  Most of the staff are here in Dallas, with some work offshore in India and Eastern Europe.  See my post on sprint planning with time separation.  The teams manage their work with Jira.

Jira synchs in both directions with Aha! Roadmaps, and will soon synch with Circle CI for deployment.  Our vision is to have a seamless pipeline from Aha’s survey portal, through feature planning, all the way to deployment.  For omnichannel retail, we add feature flagging.  We are not quite to the point of doing statistical testing and audience segmentation, but we’ll get there.

Agile teams manage their own deployments and feature branches, but releases are coordinated with Product Management and moves to production are regulated by the Architecture team.  This is designed to be a choke point for secure change management.  The Architecture team also maintains a reference library of artifacts for standardization, like federated identity.

If you’re interested in managing one of our agile teams, here is the link.  Work is onsite in our Dallas location, corner of MacArthur and 114, convenient to fine dining and Sunstone Yoga.  The facility is urban industrial, with terrazzo floors and exposed béton brut.  No remote work, sorry.  That’s so 2020.  As a manager, we’ll need you onsite.

We are looking for local talent, preferably Texans of the DFW variety.  This is to avoid relocation challenges.  There is also a certain corporate culture that comes from selling 80,000 street bikes, dirt bikes, and ATVs each year.

RumbleOn does not discriminate on the basis of race, sex, color, religion, age, national origin, marital status, disability, veteran status, genetic information, sexual orientation, gender identity or any other reason prohibited by law in provision of employment opportunities and benefits.

Not Why They Hired a Linguist

We received a resume this week listing every language from PL/1 to PHP. This fellow has some good experience, and a degree in linguistics. Someone remarked that linguistics is the master skill for programming, and then I told my story about Greg Turner.

Greg was a linguist I worked with years ago in the Wayne County public schools. He had funding to develop speech prostheses for handicapped children. Think Stephen Hawking and his artificial voice.

In the 1970s, personal computers were just coming out. The county could never afford to help these kids, except that Greg was building custom gear from scratch. We would crack open a See ‘n Say, pull out the speech chip, and order the rest from the Motorola parts catalog. That’s how I remember it. I honestly don’t know how the stuff worked.

If you studied a foreign language at university then you probably have, next to your foreign language dictionary, a grammar reference. My French grammar is the Cours Superieur. For Greg, the chip catalog was a grammar reference. It told him which chips he could use with other chips, and in what context.

I was the programmer on this project. The third member of our team was an actual EE. “Unbelievable,” he said, shaking his head. Without any training, Greg would read the specs, order from the catalog, and then build these wonderful contraptions. Salvaged joysticks and homemade head pointers. We all agreed it was unbelievable. The children just said “thank you,” with their tinny, synthetic voices.