@Athom - How could we help?

MarcelTimmermans

Hi,

This thread is just to start a positive feedback how we can help Athom the best to make it to the market. I saw a lot of issues and complains (including me) with the latest release (0.10). But I think it is in the best interest for everyone to help them and they will listen to their users.

I would really like to have a brainstorm session with a few people (on site) with them to discuss the way it goes now and how we can improve. Personally I bought homey because if has the ability to communicate with the user using speech and has a number of wireless technologies included. If this is not working I rather go to pimatic. 

So for me personally, I would like to see the following:

1. Backup and Restore tools!
2. Focus on the core OS, leave out new items. Add new items only when the core OS is good and almost bug free
3. Speech must be working great, this is the reason why I have this device
4. and step by step ad more of the wireless technologies.

I know this list is maybe differently for everyone. But I think stability is key and have Backup / Restore tools. This makes testing a lot more easier and speed things up.

Quality Control, how can we improve maybe by automated test script before you launch?

I know this experimental channel is there for testing. But this is a lot of work to rebuild all your workflows you had (I had over 50). So how we can restore them (this gives us more time for real testing  )? Don;t get me wrong here. I am happy to test, but it must be manageable. I spend this weekend most of the time to hard-reset homey and build all the flows again. There must be another way for this. I don't mind simple command line tools to start with...

Please use this thread to help Athom with suggestions and your experience!

Thanks!

mbalik79

You are right. Make the core stable before add New features. If we have an option to backup/restore it's easier to test ( instead of building all flows again and add devices). I still believe homey is a great product.  The core of 0.9.3 Was very stable over here. So why so many changes in one update. (I think it Was Better to keep the IR out this time). So when the core is stable (almost bug free) then go further. Now there a so many problems if I read the forum. Over here al the devices work, but the flows are a mess..

I want to help where I can. I believe in Athom and Homey

kludon

I want to help to. As I said in one of my treads pleasen use short minor releases instead of this Large major release with a lot of problems. Start with releases every week. And we can test these minor releases and your fixed are a lot easier because the code change is not so Big and the Community van test every week. And every week the software is getting better !! Maybe you can make one wireless Communications protocol usable at a Time and then insert the next.

EvertorN

I would suggest they look into 'feature branching'. That way Athom could do weekly releases and just release the features (building blocks) that are ready to go. It would make the 'scope' (number of features) as a driving variable rather than time. I've got the feeling Athom feels pressured to put out releases because of the community, hence the issues with the release. If they divide their work into 'features' (small chunks of work, could even be a bug fix), they can focus on delivering quality rather than quantity. 

Benefits:
- Weekly releases 
- No pressure from the community to release stuff that hasn't been thoroughly tested
- High quality releases since each feature can be properly tested

I personally wouldn't care if a release just contains bug fixes. If they can be linked to Github issues, we (the community) have insight in what has been fixed we can help testing those improvements.

RobinVanKekem

Totally agree.
I suspect we (the community) don't know half of what the last update (0.10.0) contained but I would be satisfied if only the core update was in. I.e. leaving out: iR, notification center.
After that quick fixes or bug fixes for as long as it would take to squash all bugs out of every Homey in the field (they simply can't test it all in their test environment).

If all is stable after that introduce iR or notification center (whatever is best tested or done) and squash all bugs in the upcoming weeks.

Erwin1

EvertorN said:

I would suggest they look into 'feature branching'. That way Athom could do weekly releases and just release the features (building blocks) that are ready to go. It would make the 'scope' (number of features) as a driving variable rather than time. I've got the feeling Athom feels pressured to put out releases because of the community, hence the issues with the release. If they divide their work into 'features' (small chunks of work, could even be a bug fix), they can focus on delivering quality rather than quantity. 

Benefits:
- Weekly releases 
- No pressure from the community to release stuff that hasn't been thoroughly tested
- High quality releases since each feature can be properly tested

I personally wouldn't care if a release just contains bug fixes. If they can be linked to Github issues, we (the community) have insight in what has been fixed we can help testing those improvements.

I totally agree with EvertorN (except for the weekly releasing part ). His suggestion is very much the same as how companies work that have embraced Agile Scrum as their way of working. This means a fast delivery cycle, smaller and more manageble releases, faster (automated) testing (for function, performance and regression), faster respons to changing requirements, etc. etc.

Also one of the benefits of using Agile Scrum instead of 'waterfall planning' is that you don't work time based but feature based, or even part of feature based (an emtpy framework for later releases for example). 

I work as an independed (ZZP) IT consultant currently for one of the biggest banks in The Netherlands and as such work on the biggest projects/programs within that bank. So I have 'some experience' in working both with waterfall and scrum... So to me the benefits of Scrum vs waterfall are clear. But even more important is the correct implementation of Scrum and the motivation to keep to the rules of scrum.

Mind you, I'm not implying that Athom isn´t working in a structured way, be it waterfall or scrum, because I´ve never actually been at Athom to see how they work (and I suspect most of the people on this forum also don't know). It's easy to stand along the sideline and criticize. (in Dutch: 'De beste stuurlui staan aan wal' or in English: 'Backseat drivers')...


Having said this, I would like to help Athom with there cool project Homey. So if they want, I'm available for a brainstorm session or anything else...

Annemarie

Hi guys, thanks for all your input and offering your help. For now you are doing everything you can to help us out with putting your issues on GitHub and keeping us up to date about your Homey. I will discuss all your suggestions here and let you know if there is anything more you can do!