Software Development

There are 90 posts filed in Software Development (this is page 6 of 9).

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”).

 

 

Node.js resources and other things

Freshman.tech – How to build your first website with Express and Pug

Codeburst.io – How to build a Node Weather App with 16 Lines of Code (Part 1)

Codeburst.io – Build a Weather Website in 30 minutes with Node, Express, and Open Weather

Codeburst.io – Three courses for learning Node.io

Codeburst.io – Learn Javascript by building a game

Codeburst.io – AI in the browser

Infinite Red Academy – AI Demystified – free 5 day course

 

The economics of open source development

Recently, I watched a video from JSConf.EU by CJ Silverio on the economics of open source development. She recounted the story of the start of Node.js and the Node Package Manager (NPM), and how the creator of Node.js gave the source code to the Node Foundation, but the creator of Node Package Manager retained all rights and created a company to continue development of NPM and took VC money. The video is a good watch, with lots of excellent examples on how business get value from open source software, but don’t (in general) pay anything for the software (either development or support costs). My additions to this video: (1) people who want to make money from the software they create should think hard about how they are going to do that before they start releasing that software, and (2) people who use open source for profit should invest some of their profits in keeping the wheels of progress turning (pay the developers something), otherwise the supply may dry up.

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!

Is Agile “over”?

A recent Forbes article by Kurt Cagle talks about whether the end of Agile has been reached. One quote at the top of the article was a key one:

This was no longer a methodology. It had become a religion, and like most religions it really didn’t make that much sense to the outsider – or even to the participants, when it got right down to it.

If anyone using Agile concepts has gotten to the state mentioned above, I agree that “it’s over!”. We are using Scrum at my workplace, and we have done some streamlining of the overall practice to meet our needs. So far, I would say it is working well for us. However, if I ever see the “hockey stick” mentioned at the beginning of this article, or any “religious practices”, I’ll be raising my hand to say “WAIT A MINUTE!”….

If you want to hurry, slow down

The title of this could have been “If you want to go faster, slow down”, but I liked this one better. The reason for this post is a set of events that happened to me recently, where multiple immediate actions fell in my lap. As I tried to take case of these actions, I made mistakes along the way, which slowed me down. As I was trying to solve one of these actions, other things changed which I did not know about until some time later. If I had known, I could have taken other steps to address the action. As it was, those people were hurrying as well.

What is the takeaway here? If someone presents you with a request for immediate action, slow down and think about it. Ask some clarifying questions. See if the deadline is really as dire as the person thinks it is. By taking these actions (slowing down), you have a better chance of finishing faster (the goal of hurrying). I will try to remember this when (not if) this happens to me again!

Some thoughts on first-run experience for software apps

In the past two days, I installed three digital audio workstation applications on my Windows laptop (Ardour, LMMC, Reaper). In each case, I just downloaded the latest version, did the install, then started the app. For Ardour and Reaper, both of them wanted me to select an audio input device (well, I didn’t have one!). I just clicked on something to get to the main app. For Ardour, I had to quit and try again, since the thing I clicked did not meet the app’s expectations. Only LMMC was able to start without some dialog popping up. For all three apps, I was then faced with a screen filled with various subwindows and a menu bar. What to do now?

Now, I will admit that these types of programs are complex, and require the user to know a little something about what they want to do, or how to use them. But when you compare this with many smartphone apps, there are usually some choices you can make from just looking at the screen to get started. Sure, each of the programs has some “getting started” resource (Ardour, LMMC, Reaper), but it might be nice for the app to have some built-in starter setup or task accessible from a menu (or something!). Just my two cents…