Separating "installer" development from code development

[infinitenothing]

I'm imagining a collaboration where one developer develops the code and a different developer develops and tests the installer. The only problem I see with this is by default, there's just one lvproj file with both the code and the installer build spec in it so both developers would be working on the same "file". It might be possible to make two lvproj with the build spec in one and the installer in the other. Or maybe the code developer delivers a packed project library to the installer developer?

Has anyone gone down one of these paths?

[Neil Pate]

On 9/3/2021 at 11:49 PM, infinitenothing said:

I'm imagining a collaboration where one developer develops the code and a different developer develops and tests the installer. The only problem I see with this is by default, there's just one lvproj file with both the code and the installer build spec in it so both developers would be working on the same "file". It might be possible to make two lvproj with the build spec in one and the installer in the other. Or maybe the code developer delivers a packed project library to the installer developer?

Has anyone gone down one of these paths?

Another option... Use a third party installer. InnoSetup works really well.

[joerghampel]

Generally, once the project is setup, it usually doesn't change much for us. If you're using .lvlib's and/or LVOOP to organise your code, ongoing development will not touch the .lvproj file much.

Yet another option... Have two .lvproj files: One for the developer, and another one for the installer.

[Francois Normandin]

I typically use a second lvproj file, not for installers, but for the unit testing.
The benefit is that I can segregate the dependency on the unit test framework (i.e. Caraya) from the source file that runs the build specs.

Although, I don't know if that's super useful if you use a CI server to run both UTs and perform your builds...

[infinitenothing]

On 9/5/2021 at 5:42 AM, Neil Pate said:

Another option... Use a third party installer. InnoSetup works really well.

How do you figure out the dependencies? My eyes just glaze over when I look at this screen:

[Antoine Chalons]

I'm afraid you have to use NI's installer builder to get the list of dependencies of you app. Then you can use a 3rd party product to build it.

Hopefully, over time this list will not evolve too much. Per project of course.

[Neil Pate]

14 hours ago, infinitenothing said:

How do you figure out the dependencies? My eyes just glaze over when I look at this screen:

I just include the whole runtime and don't bother trying to cherry pick the perfect dependencies. I did try this once upon a time but could never figure out the right dependencies.

[hooovahh]

18 hours ago, infinitenothing said:

How do you figure out the dependencies? My eyes just glaze over when I look at this screen:

VMs to the rescue!  Well sorta.  I'll create a VM set up the OS the what I want, then take a snapshot.  Then copy over an installer with none of those things selected and install it.  Then run all the features of my program I can think of.  If it is broken, or things seem missing I go back and try to make a new installer with something checked that I think it needs based on what didn't work.  The VM allows me to roll back to a snapshot of when nothing was installed quickly.  But yeah for the most part, this only reduces the run-time engine size a little, and while I don't like unnecessary services, spending the time to reduce them doesn't feel worth it to me.  In the past I'd spend time reducing it and making it as small as possible.  And then I'd use some feature of something like the Math Kernel, make a new build, and now things aren't working and I need to go back and update the installer.  When previously I'd just not worry about it and include everything.

[Neil Pate]

This is how I include the RTE as part of an installer.

Note: outside of the scope of the installer I manually unpack the relevant NI distributed RTE

Edited September 21, 2021 by Neil Pate

[Stagg54]

Seperate projects is not that uncommon, but I second what Neil says. Innosetup works great if you are still building installers. Much nicer than the NI build-in one and the results are orders of magnitude smaller. Offers you a lot more control too.

Lately I've just migrated to doing NI Packages instead of installers. They seem to work fine. Although you would still have the same problem with multiple devs working in parallel. 

One other often overlooked solution to the whole working in parallel problem is pair or mob programming. No need to worry branching, merging or stepping on each other's toes.

[Antoine Chalons]

5 hours ago, Stagg54 said:

One other often overlooked solution to the whole working in parallel problem is pair or mob programming. No need to worry branching, merging or stepping on each other's toes.

Do you do that?

In 15 years I only met one LabVIEW Dev who was in a job where management organised pair programming. I'd like to hear feedback from people who do that 🧐

[Mads]

2 hours ago, Antoine Chalons said:

Do you do that?

In 15 years I only met one LabVIEW Dev who was in a job where management organised pair programming. I'd like to hear feedback from people who do that 🧐

Wow, I would *never* program in pairs. Who can stay in the zone with someone else messing with the flow (see item 8 on this list...)  Working together while discussing the work and writing pseudocode is good, but while actually programming? Yuck.

To work well I need to keep and manipulate 110% of the problem in my head  (the extra 10 percent (or 200%) is the array of continuously variating attacks on the project my fantasy throws at it while I am working on it to find holes, weaknesses and opportunities in the plan 🧐) , and to do that I need to be "alone inside my head".... 

[ShaunR]

5 hours ago, Mads said:

(see item 8 on this list...) 

As an aside. Item 5 on that list is why most companies' Agile development is pants. They put all the problems in the backlog (good) then the Product Owner prioritises which ones - if any - get fed into the next cycle (bad). Companies that have a policy of addressing all the backlog issues (zero backlog policy) before working on new features in the cycle, demonstrably produce far superior code. Most companies', however, just have an ever expanding backlog and end up with tripe 10-20 iterations down the line.

[Stagg54]

On 3/21/2022 at 12:33 AM, Antoine Chalons said:

Do you do that?

In 15 years I only met one LabVIEW Dev who was in a job where management organised pair programming. I'd like to hear feedback from people who do that 🧐

I have done pair programming with clients and it works quite well. Granted these were one-off sessions working to solve a very particular problem. I mostly work alone so I haven't used it in a wide spread way, but I know people that have and are successful with it. Given the fact that most corporate management is still stuck in the industrial age, it's not very widespread. 

[Stagg54]

On 3/21/2022 at 3:42 AM, Mads said:

Wow, I would *never* program in pairs. Who can stay in the zone with someone else messing with the flow (see item 8 on this list...)  Working together while discussing the work and writing pseudocode is good, but while actually programming? Yuck.

To work well I need to keep and manipulate 110% of the problem in my head  (the extra 10 percent (or 200%) is the array of continuously variating attacks on the project my fantasy throws at it while I am working on it to find holes, weaknesses and opportunities in the plan 🧐) , and to do that I need to be "alone inside my head".... 

The Joel test was good for its time, but it's 20 years old. I think it's time we reevaluate it.

Number 8 is probably one of the most outdated. Remote work didn't even really exist back then.

Here is a more modern take on it.

https://www.sasworkshops.com/joel-3-joel-test/

[Stagg54]

On 3/21/2022 at 3:42 AM, Mads said:

To work well I need to keep and manipulate 110% of the problem in my head  (the extra 10 percent (or 200%) is the array of continuously variating attacks on the project my fantasy throws at it while I am working on it to find holes, weaknesses and opportunities in the plan 🧐) , and to do that I need to be "alone inside my head".... 

To that I would say, someone else looking at your code is much more likely to find the holes than you are. If the holes were obvious to you, you wouldn't have put them there to begin with. We inherently understand that, that's why we do code reviews. However, often the code review is too late to really change things. What if we caught those problems while they were being written and fixed them then? 

What's the old saying "2 heads are better than 1"?

[Mads]

3 hours ago, Stagg54 said:

To that I would say, someone else looking at your code is much more likely to find the holes than you are. If the holes were obvious to you, you wouldn't have put them there to begin with. We inherently understand that, that's why we do code reviews. However, often the code review is too late to really change things. What if we caught those problems while they were being written and fixed them then? 

What's the old saying "2 heads are better than 1"?

Finding problems is an integral part of coding; you code, test, code, test etc.  If you are not testing continuously and spending much more time on that than actual coding you are bound to run into serious trouble late in the project.

Code reviews? Ten people can look at the same code and think it is fine. Testing, and most importantly - testing while coding is more effective. When you think you have something completed - someone else tests it, sure. You have probably overlooked things. Again the ones that test it do it best alone (they should not be guided by you, that will reduce the likelihood of them finding errors and non-intuitive designs), and when they find something they review the code and discuss the issue with you etc. I am talking more of the creative side of coding (including the feedback from the aforementioned testing). Two heads or more should always be involved at some stage, but it should not replace the focus only a single mind can achieve.

The holes I am talking about are holes in the plan that become visible when you start to poke at it / actually execute the plan. There are no waterfall projects , you learn while doing and adjust. As for item 8 the use of remote work *is* in line with having quiet offices. For people that do not have that at home though, remote work is not a good option and we return to item 8 😉 

Edited March 28, 2022 by Mads

[ShaunR]

3 hours ago, Stagg54 said:

The Joel test was good for its time, but it's 20 years old. I think it's time we reevaluate it.

20 years ago they were building better software. Discuss 

[Stagg54]

4 hours ago, ShaunR said:

20 years ago they were building better software. Discuss 

Possibly. Depends on your definition of better. They certainly had more constraints to work within and it forced them to be more efficient with things like memory usage and storage space. One could argue that makes for better code, but optimizing for those things often compromises readability. So what do you value more? and how do you define "better" software?