Incremental Programmers Finish First

---

New programmers often try to eat the elephant all at once. This video talks about how to go about building software incrementally for a safer, saner, more predictable workflow.

About me: I'm a computer scientist, researcher, teacher, and Internet of Things enthusiast. I teach systems and networking courses at Clemson University. I lead the PERSIST research lab, where we develop new technologies for wearables, batteryless sensors, and other ultra-low power devices.

More about me and what I do:



***

Welcome! I post videos that help you learn to program and become a more confident software developer. I cover beginner-to-advanced systems topics ranging from network programming, threads, processes, operating systems, embedded systems and others. My goal is to help you get under-the-hood and better understand how computers work and how you can use them to become stronger students and more capable professional developers.

About me: I'm a computer scientist, electrical engineer, researcher, and teacher. I specialize in embedded systems, mobile computing, sensor networks, and the Internet of Things. I teach systems and networking courses at Clemson University, where I also lead the PERSIST research lab.

More about me and what I do:

To Support the Channel:
+ like, subscribe, spread the word

Want me to review your code?

You can also find more info about code reviews here.

[unperrier]

It may seem stupid to write the test before the code, but it has a great advantage: the resulting code is testable.
By testable I mean the test doesn't act on a 500 lines function that has a good dozen of inputs.
Instead you write a test that is minimal, that just does what is needed, without thinking about what goes in it, and then you code it and you end up with small code that does one thing very well and tests that are simple.

[alysson.cirilo]

Thanks for all the good videos man.
I wish more people knew your work.

[BritishBeachcomber]

When I introduced incremental development the CEO kept asking "but where's the product, can I see it working?" Then it all fell into place. And it worked. Then he understood.

[edgeeffect]

I like that way that at 1:14 the debugging bar actually goes off the edge of the screen. Back when I was a student, I watched that bar go so far off the screen, I'd need another laptop 500 miles away to see the other end.
I'm just thinking back to those days and some of us would solve a problem in say 10 pages of Cobol (it was all paper print-outs in those days) and other people would be working on the same assignment and end up submitting 50 pages or more. (sorry just remembering out loud)

[mayankpant]

I'm in second year of cse and there is this subject called "software engineering".
We are taught the same thing you said here, it's called life cycle process and it has various models which can be used when developing a software.
One of those is called spiral models which is like the best of them .

Noone in the class and even me is remotely interested in this subject because it has a lot of theory and not much to do other than memorise, but once you actually read the book you realise that it might come in handy later down the line..

[LinucNerd]

Wow, I never thought about this... Now I know why some projects of mine have worked really well and others have not - I've switched between those two methods without ever thinking about it xD

[frozentomatoman]

Hope I have seen this 2 years ago.
Learnt it the hard way.
"Dont write 10 lines of code without testing."

[harrirahikainen]

Would love an example of how to set up your makefile with test targets and release executable

[fmitchella]

I was a little amused by another comment saying unit testing wasn't possible "normally". I've championed Unit Testing in many companies I've worked for, and it usually goes OK. Still, I can think of a few reasons why automated testing and incremental development might not work in all cases:

1. One has to extend an existing code base with few if any tests. Thus one has to first find smaller testable bits, put in unit tests to explore their existing behaviors, *then* start coding and testing your project that modifies or interfaces with them. Management and senior developers consider the whole thing a "waste of time" when there's _production_ code to write.

2. The existing code base is a tangled mess, which makes the situation in #1 harder.

3. Despite their enthusiasm the organization's champion doesn't have a lot of experience with TDD or unit testing. Earlier in my career I found myself testing too many of the wrong things, e.g. internal mechanisms, and not enough of the right things, e.g. erroneous external input and I/O error cases. This often leads to a lot of work writing and maintaining tests with little benefit that may need to be thrown out if the internals change while external, observable behavior gets short shrift. This inevitably makes the whole idea look bad to the naysayers.

4. Management doesn't support automated developer testing as a legitimate activity. They count progress in self-reported use cases or "function points" completed and leave QA to do testing. Thus developers who stop to test their own code are considered "slow".

All of these strike me as organizational problems masquerading as technical problems. (Particularly #4.) In my experience, though, organizations would rather not admit their existing code base is a Big Ball of Mud, their corporate culture dismisses new ideas without an unbiased trial (the infamous Not Invented Here syndrome), and their development cycle is dysfunctional. I've also seen organizations embrace automated testing a little *too* eagerly, with code coverage metrics used as yet another yardstick with which to beat developers.

This ran long, but in brief: automated code testing, unit testing, and TDD *should* work and *does* work in many instances, but it's sometimes defeated by social and psychological factors.

[muesique]

2:35 Not always the case when you put together two or three peaces of existing code. There may be problems in the old code as well! Especially when using global variables. Or you had magic numbers or code just work in the old path.
I code in tcl where it's very easy to work incrementally.
Long coding sessions without testing or implanting routines from other projects without careful probing resulting longer debugging in the end. When I take snippets of code from other projects they are as small as possible. Often I just take the basic functionality and go up from there. I too often ended with completely wrong behavior when I thought I was making no mistake. But in 999 out of 1000 the compiler or the interpreter is right! ;)

[kushagrakumar]

Could you please explain / demonstrate in detail how to automate the tests the way you shown in 3.26 ?

[RurikLoderr]

I have a mantra I tell myself while programming whenever I notice I'm trying to tackle too much at one time... "Just get it working, stupid."

[ABaumstumpf]

Would that be nice if the "incremental" programming was possible normally. It works if you have small independent things to write and all other code has been tested to hell and back.
But for me it is not uncommon that i write code for 2-3 days and the only tests are code-compile and some really simplistic auto-tests that check the source for things like "if(comparevalue = 0 )".

In our team we got one person that constantly wants to try those things like test-driven-development. Just that he took longer to write even the basic test-functionality as the code is linked with many other things (like database-connections as well) and creating the test-cases manually is out of question when the scenarios to be tested involve docents of independent inputs and hundreds of scenarios that would need to be written out. So he wrote a tool to extract the input-data and output from test-examples and had to hand-check them all.... i think he ended up with like 50 test-scenarios and took longer to write the tests then doing all the coding and manual testing.

I had a similar problem where the requirement was having a package and finding a specific target based on the available space and task on that target.
Not much you can test other than the whole thing at once and the hard part being all the sorting. Changing the way the objects and targets get sorted also frequently meant changing the data-structure so any prior test-results would be invalid at that point anyways.

[sparrowhawkguitarboy]

Great Video, the thing I can’t find enough Literature about testing in C

[rustycherkas]

#include <stdio.h>
void main( void ) { printf( "Hello Wirld\n" ); }
**FAIL**
🤣