software-dev

recent posts related to software development

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.

Jenkins tutorials (Jenkins, Docker, Scala, SBT, Java, Maven, and Git)

As a brief note to self, these were the two best Jenkins tutorials I found in early 2019:

The first one shows how to run Jenkins with Docker, and the second one shows how to build a Java/Maven/Git project.

This tutorial on how to use Jenkins with Scala and SBT was also helpful:

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 three things a Business Analyst should think about during meetings

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.

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