elementary-dev-community team mailing list archive
Mailing list archive
Re: Congratulations Luna developers!
Ok, I have not added a single line of code to elementary yet, and gave some
decent amount of headache to real devs around here. I have though
participated in development of many products, small and large, and so here
TDD in its pure form requires having tests written and ready before the
code is written. Then failing tests are being implemented one by one,
having the code both tested and working in the end of this process. I
highly doubt that any of Elementary devs have the capacity or the will to
follow this. Especially, when many of our projects are built using 'try and
error' methodology, that is they follow the 'Hey! Let's try this!' rule.
Which is awesome, as it allows fast development and really quick release
Now, what I think would fit Elementary much better is simply testing (yes,
that QA thing everyone loves and adores) - the T from TDD, which is the
most important part. The best way to do that is, of course, to create a
bunch of automatic tests, but that's not really feasible either. So as I
see it, we can do 2 things:
1. Start looking into unittesting as much and as early as possible, and
have devs starting to create tests. This has the benefit of devs learning
to create unittests and having some of the code tested, and also,
potentially, at some point, it could help moving to real TDD.
2. Start creating manual test procedures for basic staff. Yes, it requires
a lot of human power and time, but also do translations. This is the most
boring part of software engineering, but it is the one that can bring
balance to the force. Also, some of these can sometimes be automated too,
so it's not all that aweful.
I personally think we need both 1 and 2. I am a strong believer in testing
as means to improve the product. But TDD is probably an overshoot in our
case. We need to start with *something*, and right now we don't really have
On Sun, Aug 18, 2013 at 8:41 PM, Craig <weberc2@xxxxxxxxx> wrote:
> I posted the following message on Google Plus yesterday, but it occurred
> to me that the weekend may not be prime time for checking that social
> network. I think this message is pretty important, so I want to post it
> again here: (I apologize in advance for its length)
> Congratulations to all the developers who made Luna such a success!
>> You've done a great job and delivered an incredible Linux experience!
>> I know I bring this up periodically, but I'm concerned that Luna + 1 and
>> future releases will take more and more time to release, and/or that you
>> will quickly reach a ceiling with respect to the amount of code we'll be
>> able to maintain before quality degrades.
>> The cause for my concern is the nature of complexity: as software grows
>> (that is, as code is added), bugs grow exponentially (complexity increases
>> exponentially with logic, and bugs grow linearly with complexity). If we
>> don't start working toward solutions that will scale with this problem, we
>> **will** hit a ceiling with respect to the amount of complexity we will be
>> able to support (this means fewer features or less-powerful features). I
>> I know some in the community are working toward this goal, but I think
>> it's going to take a concerted effort on the part of the developers to take
>> this problem seriously. I urge you all to take this problem as seriously as
>> you take the rest of the user experience (because bugs are, at the end of
>> the day, a sharp degradation of the user experience).
>> In my experience, the silver bullet for combating this problem is test
>> driven development. If you look around the software development industry,
>> code is improving, and it's largely because TDD is catching on. And Google
>> is a good role model in this regard (not just for us, but for
>> everyone--they are pioneers of code quality). If you're a developer and
>> you're unfamiliar with TDD, take some time and research it. It will pay
>> dividends immediately. If you have any questions about development, I'm
>> happy to provide my advice as a professional developer. Also, read up on
>> Google's testing strategies (I recommend
>> http://www.amazon.com/Google-Tests-Software-James-Whittaker/dp/0321803027_How Google Tests Software_).
>> You guys are a _great_ UX shop, now let's become a great code shop. I
>> hope this analogy doesn't offend anyone who is passionate about their tech
>> brands, but my advice is this:
>> Design like Apple, develop like Google.
>> I really push you developers to continue to strive to hone your craft the
>> way Daniel and Cassidy (and any other UX designers) are learning to hone
>> P.S., Sorry for the book, and I hope you all take this as respectful,
>> constructive criticism. _Please_ ask me anything about development,
>> especially with respect to how we can keep quality high using processes
>> rather than sheer developer effort (so as to free you developers to work on
>> interesting problems rather than bug hunting).
>> Thanks for reading,
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help : https://help.launchpad.net/ListHelp