Saturday, January 12, 2019

What is Software Value?

In software development, we are often asked to deliver value instead of hype, flash, or even pride. Yet, what truly constitutes value? Isn't value subjective? Isn't value the sole concern of the business? Isn't value a vague term? Isn't delivering value as obvious as doing what the manager asks you to do? How about value being as obvious as making people feel good?

So many questions, which I'd like to address from personal success and failure experiences in delivering value to customers.

Last year, after moving to my new place in downtown Chicago, I wanted to get the fastest Internet connection available. I found out it was Xfinity's 1Gbps Cable Internet, so I bought the best Cable modem I could find at Best Buy (supported up to 10Gbps speeds) and then visited an Xfinity store to order the Internet service. The timing was perfect! It was during the Winter Olympics, so I got to enjoy seeing on Cable directly or streaming over 1Gbps Internet. I was working from home with UpCity Inc at the time, and work was going smoothly thanks to the high speed Internet. Unfortunately, that only lasted one week, and then speeds dropped to 100Mbps, wasting my investment in expensive hardware and reverting me back to Internet speeds from 10 years ago. I contacted Xfinity's tech support and they did nothing but give me excuses and claiming 100Mbps was good enough when I was paying the hefty price of 1Gbps Internet. That's a side effect to the recent onslaught of hiring of underqualified employees, but I won't get into that for now. Needless to say though, I checked the closest competitor, and AT&T was offering similar speeds over fiber optics. But, my building didn't support yet, so I settled for 18Mbps. Yet, they were honest, prompt, didn't give excuses, and made me feel very well respected for the money and the individual I am. Whereas Xfinity's offering delivered the fastest Internet I could get (100Mbps down from 1Gbps), AT&T delivered happiness with only 18Mbps, supporting all 4K TV streaming and HD sports watching needs. This story pretty much sums up the definition of value in software delivery.

So, back to the questions, which I'll answer individually.

"what truly constitutes value?"

Doing what's right! Which results in customer happiness, respect, the feeling of appreciation, the feeling of being estimated fairly as opposed to thinking of customers as below the company serving them, and serving the customer true needs by providing substance, not flash, by providing true benefits, not pointless pride.

That said, to keep doing what's right, the business must be profitable enough to keep employees motivated to do great work. So, value must account for that as well. It must respect employees' and businesses' limits while ensuring business sustainability. Value delivery is work not charity. So, it is important to respect your manager's perspective when suggesting ideas as they know more about what the business could afford to do for customers.

"Isn't value subjective?"

Value can be subjective, yet all of us are human subjects, and thus share a common thread in what makes us happy and share the gift of discerning what can truly benefit others (often without needing to ask). As an example, in UX (User Experience) Design usability testing practices, they recommend observing the users and discerning for ourselves what can serve their needs best, not always following what they say, yet following our instincts instead, resulting in much better software experiences.

"Isn't value the sole concern of the business?"

A business that operates that way is treating its employees like machines as opposed to similar human citizens of their society. Any good business would allow its employees room for discerning and sharing value with their customers.

"Isn't value a vague term?"

All terms are vague if you don't share context with others. That's why, it's very difficult for someone living abroad to deliver value in the USA. And it's more difficult for someone living in Washington to deliver the best value in Illinois (albeit not impossible, Amazon does a good job of it).

Yet, keeping value delivery in mind instead of abandoning as a vague term focuses us on doing what's right and truly serving the needs of customers. Otherwise, we risk getting lost in copying the competition or offering people what they say, without satisfying their needs.

"Isn't delivering value as obvious as doing what the manager asks you to do?"

It could be if you're a junior software developer unable to discern value yet. As you grow and progress in the field though (yet more often even as a junior), you start bringing your own perspective to what value is and better discern what better serves both the business and the customer.

"How about value being as obvious as making people feel good?"

Feeling good is not the same as being happily satisfied with service due to needs being served. Besides, sometimes the user is getting work done with software, and what serves their needs is getting work done correctly and fast, which might not feel good, but it feels right! So you wouldn't target them feeling good or else you risk falling into the trap of offering them irrelevant features like background music playback through online spreadsheet software. Instead, you target doing what's right for the business and customer by figuring out how to best serve their needs (e.g. cloud storage of spreadsheets instead of requiring upload/download on every use).

One last bit of wisdom on the topic since wisdom is what you'd expect from a blog is staying open-minded about the perspectives of your colleagues and coming up with a best value delivery solution through collaboration and respectful goal-oriented discussion (no senseless arguments or pride-asserting debates). I like to share just enough of my opinion, while leaving it to the highly skilled web designers and software architects to iron out the details of what they're best at and I'm not so good at.

In summary, deliver value, not pride! Keep the business and colleagues in mind in value delivery. Focus on customer needs not wants.


Saturday, November 25, 2017

puts_debuggerer 0.8.0 is out!

puts_debuggerer, the library for improved Ruby puts debugging, now has better support for Rails.

In a Rails environment, puts_debuggerer now automatically outputs to Rails logs at the debug level. This is facilitated using the new "printer" support, which is a configurable option that comes with smart defaults.

The "printer" option value can be a global method symbol or lambda expression to use in printing to the user. Examples of global methods are :puts and :print. An example of a lambda expression is lambda {|output| Rails.logger.info(output)}
It defaults to :puts , but if Rails is detected, it defaults to: lambda {|output| Rails.logger.debug(output)}
Example:
# File Name: /Users/User/example.rb
PutsDebuggerer.printer = lambda {|output| Rails.logger.error(output)}
str = "Hello"
pd str
Prints out in the Rails app log as error lines:
[PD] /Users/User/example.rb:5
   > pd str
  => Hello

Learn more about puts_debuggerer over here: https://github.com/AndyObtiva/puts_debuggerer

Monday, October 23, 2017

Sunday, August 06, 2017

Ultra Light Wizard v0.1.4 Wizard Step Breadcrumb

Ultra Light Wizard just got an update (v0.1.4). It now ships with a wizard step breadcrumb like the one in this screenshot:



Its semantic markup and CSS is easily stylable and customizable, especially to developers well-versed in HTML5 and CSS3.

Enjoy!

Saturday, July 29, 2017

How To Test-Drive Rails Generators?

Rails generators are a form of meta-programming in Ruby. They're basically programs that write programs. To be more specific, in my open-source project Ultra Light Wizard (also a pattern presented at RailsConf 2014), the Rails generator ultra_light_wizard:scaffold generates models, controllers, views, routes, helpers and a migration automatically when the user wants to build a wizard.

How does one test-drive such a Rails generator though?

I started by writing a standard RSpec test and then quickly realized that if I were to test-drive what each file generated contains, I'd be opening a can of worms and getting lost in so much unimportant detail.

Then, I had an idea. Why not create a full-fledged Rails app as a fixture and place it under the "spec/fixtures" directory?

Next, how about I configure the app exactly as needed to run the generate command from a test, but then during the test, I leave it untouched and copy it on every test-run to avoid messing up the reference version?

Well, to explain, you end up with an RSpec test that looks like this:


Now, comes the tricky part. How do you test by invoking the generator on the project copy?

Well, I took the easy way out and simply dropped down to the shell from Ruby as follows:

In other words, by invoking "rake" from the Rails project copy, I started another RSpec test suite run from within my main test suite. Totally meta, eh!?

Now, here comes the meat of the work, in the form of feature specs written for the Rails project copy. To explain, the tests shown below are written from the user's point of view for the effect of running the generator in a real Rails app (the top part consists of helpers [e.g. fill_in_project_fields] and the bottom part has the test cases as "scenarios" [e.g. scenario 'can start wizard']):

And with that... problem solved. Here is an example test run:


Notice how the inside RSpec test-run (from the reference Rails project copy) reported 5 examples, and then the outer RSpec test-run reported 1 example (the one that spawned the rest).

Pros to this approach are success in covering end-result of generation, and decoupling tests from detailed work of generator.

Cons are obviously increased complexity, albeit that is balanced with decreased complexity of writing the inner integration specs and freedom of implementation.

How have you handled Rails generator testing in the past? Care to discuss pros and cons?

Wednesday, July 26, 2017

Self-Installing Apps

I have recently explored the idea of self-installing apps while implementing the new Glimmer executable.

What do I mean by a self-installing app?

An application that requires external dependencies, potentially written in multiple languages/technologies, and can handle self-installing them upon first-run via a simple seed command.

Think of it like a seed of a bean plant, which you'd plant (download), water (execute), and then voila, a full-grown app sprouts up, grabbing extra components off the Internet as needed.

To translate this into my example above, Glimmer, has a non-ruby dependency, SWT.jar (Java Archive), which must be setup properly for Glimmer to work. As a self-installing app however, it detects whether SWT.jar is available or not on the first run, and automatically downloads and installs it if unavailable, or otherwise uses it and runs without a hitch. That works on Mac, Windows, and Linux with both x86 and x86-64 CPU architectures.







Self-installing apps are nothing new, but I am documenting my first venture into it in JRuby (albeit I've collaborated with a developer in the past who wrote such an installer for an application I built at a past company I worked for)

I shall explore the idea of having self-installing apps auto-update themselves as well in the future. Stay tuned for a blog post about the subject if I do implement.

Would it be a good idea if all software was self-installing and self-aware? Please share your thoughts in comments.

You may try Glimmer over here.

Glimmer Ruby Desktop Library Version 0.1.9.470

Glimmer Ruby Desktop Library Version 0.1.9.470 is released!

It now supports one-way Tree data-binding similar to that of SWT Table.

Example:



You may learn more from the screenshot and rspec test included below.


Happy Glimmering!