Posts in the “software-dev” category

The three things a Business Analyst should think about during meetings

[toc]

When it comes to working as a business analyst, I’ve learned that there are just three things you need to keep in your mind when meeting with your customers (the project sponsor (gold owner) and domain experts (“goal donors”)) to gather requirements. These three thoughts will keep your meeting on track, lead you to the next question, and will help you know when your work is done.

Applications I’ve written

This is a list of some of the applications I (Alvin Alexander) have written. I’ve included links to places where you can find more information about each app or application.

Just Be

Just Be is a mindfulness reminder application for Android. Being an Android app, I wrote it in Java. You can learn more about it at JustBe.cc.

Cato: A template based, database driven source code generator

Welcome to the main page for my Cato CRUD generator application. Getting right into it, here’s what the marketing department says about Cato:

“Cato is a free, open source, template-based, database-driven, GUI app that lets you generate text -- source code, configuration files, etc. -- for any programming language or tool, based on the tables in your database.”

If you know what the code generator does in Ruby on Rails, Cato works just like that, but it’s not specific to any programming language or framework.

The Chrome JavaScript debug console and [Object object]

As I’ve gotten back into client-side web development -- specifically using Sencha Touch 2, a JavaScript framework -- I’ve quickly run into a problem in the Chrome JavaScript debug console. When I try to use console.debug() to debug an object, I get this non-useful output about the JavaScript object I’m printing:

[Object object]

There may be better ways to print the desired object, but I quickly discovered this trick to printing all of the properties of a JavaScript object:

An initial thought when taking the time to create a new app or utility

Sometimes when I embark on little projects like my Scala file-find command, I think, “This is a waste of time, the existing tools are good enough.” But then, if I’m motivated enough — if I really want something — I think, “But I can use this better tool for the rest of my life...”

I just released the file-find command four days ago, and I use it almost every day while learning Flutter and Dart, so I think it’s going to be well worth it.

People don’t want to use your software

This “People don’t want to use your software” quote by @SHL seems pretty smart. And Gumroad does a pretty good job of keeping their software simple.

I was actually thinking a little bit of the opposite yesterday; I thought, “I could care less about Apple hardware, I just like MacOS, or at least I used to love what it used to be.” But in the end I don’t really love the software, I just like that it works how I think an OS should work, and it has a Unix terminal that I keep open all the time.

If you build the wrong application, no cool new technology will save it

Paraphrasing someone tonight: “I worked on cool projects X, Y, Z with cool new technologies A, B, and C. They all failed. Nobody used them. The only app customers still use was written in lowly old PHP. And the customers love it.”

I took that as, if you build the wrong application, no cool new tech will save it.

Measuring Scrum team productivity/speed with Function Point Analysis

I bought my first copy of Agile Software Development with Scrum, by Schwarber and Beedle back around 2002, I think. I was just thumbing through it last night when I saw that they use Function Points as a metric to demonstrate the velocity that agile software teams achieve, and more specifically use it to show that some teams develop software much faster using Scrum.

I didn’t know about Function Point Analysis back in 2002 — I didn’t become a Certified Function Point Specialist until about two years later — so I probably just skimmed over that line then, but when I saw it last night I thought it was cool that they used function points as a metric for software team development speed.

The “No New Rationale” rule

I like the “No New Rationale” rule, which I learned about in this blog post by Aaron Turon, who writes about the Rust RFC process:

No New Rationale rule: decisions must be made only on the basis of rationale already debated in public (to a steady state).”

“At some point, a member of the subteam will propose a “motion for final comment period” (FCP), along with a disposition for the RFC (merge, close, or postpone). This step is taken when enough of the tradeoffs have been discussed that the subteam is in a position to make a decision. That does not require consensus amongst all participants in the RFC thread (which is usually impossible). However, the argument supporting the disposition on the RFC needs to have already been clearly articulated, and there should not be a strong consensus against that position outside of the subteam.”

The place to fight design wars is in new markets

“When Yahoo bought Viaweb, they asked me what I wanted to do. I had never liked the business side very much, and said that I just wanted to hack. When I got to Yahoo, I found that what hacking meant to them was implementing software, not designing it. Programmers were seen as technicians who translated the visions (if that is the word) of product managers into code.

This seems to be the default plan in big companies. They do it because it decreases the standard deviation of the outcome. Only a small percentage of hackers can actually design software, and it’s hard for the people running a company to pick these out. So instead of entrusting the future of the software to one brilliant hacker, most companies set things up so that it is designed by committee, and the hackers merely implement the design.

If you want to make money at some point, remember this, because this is one of the reasons startups win. Big companies want to decrease the standard deviation of design outcomes because they want to avoid disasters. But when you damp oscillations, you lose the high points as well as the low. This is not a problem for big companies, because they don’t win by making great products. Big companies win by sucking less than other big companies.

So if you can figure out a way to get in a design war with a company big enough that its software is designed by product managers, they’ll never be able to keep up with you ... The place to fight design wars is in new markets, where no one has yet managed to establish any fortifications. That's where you can win big by taking the bold approach to design, and having the same people both design and implement the product. ”

~ I hope to write more about this at some point, but for now this is a long quote from a Paul Graham blog post titled, Hackers and Painters