Software Engineering

There are 42 posts filed in Software Engineering (this is page 1 of 5).

Co/Recursive: Beautiful Code – Inside Greg Wilson’s Vision for Software Design –

Greg Wilson has been on a decades-long quest to transform how we teach and talk about software design. From getting rejections for using the term “beautiful code,” to empowering scientists through workshops on Python and Unix, Greg has pushed to bridge the gap between theory and practice.

Join us as Greg shares his failures and epiphanies along the way. You’ll hear how he revolutionized research computing by showing physicists the power of profilers. How he taught grad students the elegance of shell scripts. And how he’s crusaded to create a shared language to discuss software architecture with the nuance of true craftsmanship.

Greg’s captivating journey reveals that with perseverance and the right examples, we can elevate software design discussion to an art form. But that we’ve got a long way to go. You’ll come away enlightened and eager to level up your own understanding of software design.

Greg Wilson: Eleven Tips for Organizational Change “This was a proposal for the US Research Software Engineer Association 2023 conference, but was rejected…. I recognize that they are incomplete—in particular, that they are strongly biased toward what works in affluent, democratic societies—but if you’re tired of rolling heavy rocks up steep hills over and over again, maybe they will help.”

Booklist Browser app update

This weekend, I moved my cut at Booklist Browser app requirements from the Github issue to its own page. Next, I took a cut at defining the possible domains for the Booklist Browser app, using concepts as described in “How to Engineer Software” by Steve Tockey (https://www.construx.com/books/how-to-engineer-software/). My next step will be to define use cases based on the domain definition and requirements.

Bookmarked Rules of thumb for a 1x developer (muldoon.cloud)

Contents Contents Preamble I have little to say that’s of general value and haven’t found the time to level up My theory of bootstrapping The Rules Meta Rule 1: Rules are good Productivity and learning Rule 2: Most of what I learn is useless outside of its immediate context Rule 3: Focus “lear…

An essay from an Amazon developer looking to improve his skills, he shares his experiences at Amazon in a set of programming rules.

“I’m not a 10x developer….I was not That Guy overachieving on nights and weekends….In summary, I am a 1x developer. I do enough to get by respectably.”

Paying for the development of software

I recently read a post on funding of software developed for academic/research use, the author stated that many grants are for new applications, and that funding agencies should consider supporting existing open source software that goes unfunded. There were links to papers such as the development of AstroPy, and a report by Nadia Eghbal on funding of Internet digital infrastructure development.  I have touched on this topic before in a recent post about the development/funding story of the Node Package Manager. All of these stories touch on some common problems:

  • People write software, put it out on the web, people use it or they don’t.
  • If a lot of people start using it, and start asking for features/fixes, how do those get done? How do the developers get reimbursed for their time and effort?
  • What if a business uses open source software at no direct cost? How can they depend on that software being supported and available?

Businesses that develop physical products that contain custom software pay for that software as part of the development cost of the product. This may be the best example of funding for software development.

To me, the idea of a subscription fee makes the most sense. The user paying a fee gets a specified level of support, for example, or early access to new versions. The developer gets a steadier stream of income than one-time payments (like for smartphone apps). There are other problems to address that I am not going to solve in this post, but people who develop applications should consider these topics before starting (they should “count the costs”).

 

 

Is good code boring?

Juraj Malenica writes saying “You should develop boring code”. His post highlights the following:

  • Make your code readable
  • Keep your code predictable
  • Your code is your documentation

If we take these as attributes of “boring code”, are these also attributes of “good code”? Let’s take a look.

Code readability (the ability to understand a source code function) is a good one. For most of my career, I have been working with existing code bases, and ability to understand what has been done before is very important. Working in the avionics industry, requirements and traceability go a long way towards helping understanding legacy software. If this is not available, avoiding the use of difficult-to-understand coding techniques can enhance readability.

In Juraj’s post, code predictability covers naming conventions for parameters/functions/files. For the projects I have worked on, coding standards help to define these conventions. Juraj mentioned a Python standard, there are many available.

Finally, code as documentation is a good goal. If there is no other project documentation, the source code should contain all the information necessary for another developer/engineer to pick up the code and add new features.

After this review, I would say these “boring” elements are also included in code that would be considered “good”. Is this everything needed? No (it is necessary, but not sufficent), but this is a good start.

How can we work together on the open web and on software development

I have been in several conversations in the last week (voice and email) where the concept of “working together” in software development came up, and several threads emerged:

  • how the original developer doesn’t/shouldn’t have to do everything – others can contribute (to me, a key concept in open source)
  • how interested/engaged users can be an important force in the direction in which a software application or tool goes forward

Dave Winer has written about this many times:

I have tried to follow that second point in several ways:

I am getting ready to start working in the computer music area again after a long absence, and I am reviewing available tools to see if they fit the areas I am interested in. In that way, I am trying to practice the concepts of working together as I have outlined above.

Anyone want to work together with me? Let me know!