Software Engineering

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

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…

They don’t make them like they used to…

Ken Shirriff has restored an Apollo Guidance Computer (AGC), used in the Saturn V spacecraft. He recently published an article on how the power supplies still worked flawlessly after 50 years. Recently, two embedded computers that I work with burned up their power supplies, so this is really impressive to me! Ken has also written articles on creating a core rope simulator (the way software was programmed), writing software on the AGC to do bitcoin mining, and a more detailed discussion of core rope memory. Finally, he has references to a virtual AGC simulator, and to a great summary page on simulated AGC projects. Wow!

How should developers build apps?

Earlier this week, I read a post titled “Build Libraries, Not Apps“, where the author (Nicolás Ortega Froysa) puts forth an idea that software developers should create the main part of their applications as libraries, then create APIs so that other developers can create alternate user interfaces in other clients if desired. I can see that being an appealing goal for developers who want their application to be used in lots of other settings. However, I do not think that most applications are designed to have alternate user interfaces. For myself, I think of the user interface that I want my application to have, and then create it, and then create the logic that powers that interface. It is not a design goal for me to support an API. Froysa mentions different ways that Unix/Linux applications can interact with libraries (GUI, text interface, command line interface). To me, if a design goal of the application is to support multiple clients, or provide services to other applications, then including an API makes sense.

Building community

Ton Zijlstra commented on a post by Chris M about what would be a critical mass for a community. In Ton’s reply, he links back to a post, which links to a presentation on steps to consider in building/starting a community. I think the presentation contains some excellent material. I participate in a biweekly meeting of software engineers at my workplace (using the Lean Coffee format), and feel we have made some good progress in turning that into a community of practice. Reviewing this presentation, I can see some areas that we might be able to improve on. I hope to pass on some thoughts to the group leadership..

Please have a little respect for the past

I enjoy reading Philip Greenspun’s weblog, and he certainly has experience in aviation and software development. His recent post on visiting the Museum of Flight in Seattle throws quite a few digs at the US space program and people who have been a part of the effort. I worked at NASA and Lockheed in Houston from 1985-1997 on the Space Station program, and had the opportunity to work with a great group of people, both contractor and civil servant employees. Things were contentious at times (usually dealing with funding issues from Congress and the Administration), but we got the job done (flew Space Shuttles, came back from the Challenger accident, got the Space Station program back on track). I know that Philip likes to find fault with many things in the United States (and I agree with most of it), but I think he might want to stay with areas he has expertise in and not look for other ways to poke people in the eye.

Haste makes waste, part 157

In today’s episode, I lament when the rush to meet a deadline means that the software is not checked out sufficiently, and multiple problems/errors are discovered, most of which have to get fixed later. Sigh…

Sometimes there are business reasons for shipping something by a certain date. The cost of meeting that date, though, sometimes includes future payments to correct problems. There is no “one size fits all” answer to this topic, but the cost of corrections should be considered as part of the overall cost (unless schedule is king, which means resources will be made available to fix what needs to be fixed). Thoughts, anyone?