pages tagged new-projectyakkinghttp://yakking.branchable.com/tags/new-project/yakkingikiwiki2017-11-22T12:00:16ZStart using your new project earlyhttp://yakking.branchable.com/posts/use-early/Lars Wirzenius2017-11-22T12:00:16Z2017-11-22T12:00:08Z
<p>You've started a new project. When should you start using it "in
anger", "for real", "in production"? My advice is to do so as early as you can.</p>
<p>I did this for my newest project. I've been developing it slowly, and
things had matured enough that it could now actually do things. I set
up two instances doing things that I, and my company, now rely on. If
the software breaks, I will need to take action (disable the broken
instances, do things in another way until I fix the software).</p>
<p>The point of doing this early is that it gives me quick feedback on
whether the software works at all, and makes it easy to add new
features, and makes it easier for others to try out the software.
(When I announce it publically, which I'm not yet doing.)</p>
<ul>
<li>I see quickly if something doesn't work. (For now, it does.)</li>
<li>I see at once if there's a missing feature that I urgently need. (I
have found two bugs yesterday.)</li>
<li>I see what is awkward and cumbersome for configuring, deploying the
software. (So many interacting components.)</li>
<li>I see if it's nice to actually use. (I need to find someone to write
a web interface, and need to improve the command line tool.)</li>
<li>I see if the performance is adequate and get an idea what the actual
resource requirements are. (Not many resources needed for now. Even
the cheapest VM I could choose is adequate.)</li>
<li>I get more confident in the software the more I actually use it.
Writing a test suite is good, but real use is better. Real use
always comes up with things you didn't think about writing tests
for.</li>
</ul>
<p>In order to set up not just one but two instances, I had to make the
deployment automated. (I'm that lazy, and I don't apologise for
that.)</p>
<p>Thanks to an automated setup, when I add features or fix bugs,
they're easy to roll out. It's now almost as easy as just running
the program from the source tree.</p>
<p>My development process is now, I write tests; I write code; tests
pass; I tag a release; I let CI build it; and I run Ansible to upgrade
everywhere. About 15 seconds of work once the tests pass, though it
takes a couple of minutes of wall-clock time, since I run CI on my
laptop.</p>
<p>Apart from the benefits that come from the features of the
software itself, getting to this stage is emotionally very rewarding. In
one day, my little pet project went from "I like this idea" to "it's a
thing".</p>
<p>I recommend you start using your stuff in production earlier rather
than later. Do it now, do it every day.</p>
New project? Start with the scaffoldinghttp://yakking.branchable.com/posts/scaffolding/Lars Wirzenius2017-04-05T11:00:12Z2017-04-05T11:00:06Z
<p>So you're starting a new project. You have an idea for something, and
a vision for how to implement it. What should you do first?</p>
<p>If you're like me, you burn to start with the interesting coding bit
first. After a few hours of furious typing, you've done the fun bit,
and you need to add all the boring bits: automated tests (unless you
did TDD, and even then there may be missing tests), documentation, a
manual page, a README, perhaps packaging (Debian, RPM, language
specific), a CI project, a home page, etc. There's a lot of it. That
is usually when my enthusiasm fades. A lot of my projects end up as a
single file in <code>~/bin</code>.</p>
<p>I call the boring bits scaffolding, and I've learnt that it pays to do
them first. Not only is that often the only time I will actually do
them, but once the scaffolding is in place, the fun bits are also more
fun to do.</p>
<p>If I have unit and integration test frameworks in place, adding
another test is only a small incremental task. If I haven't got them
in place (particularly for integration tests), I tend to postpone
writing tests. No chance of TDD, whereas when I put in an integration
test framework, I often to TDD at the program level, not just at the
individual class and method level.</p>
<p>Likewise, if I start by writing a manual page, adding another sentence
or paragraph is easy. Also, writing a manual page, or any
documentation, clarifies my thinking about what the program should
actually do, and how it should be used. This makes writing the code
more pleasant.</p>
<p>Having CI in place from the beginning, means the tests I write get
exercised from the start. This finds bugs earlier, even if I run my
tests manually as well. CI never thinks "I can run test faster this
one time by taking this clever shortcut".</p>
<p>Of course, putting up a lot of scaffolding takes effort, and it's all
wasted if you don't actually want to write the program after all.
Sometimes what sounds like a brilliant idea on the last train home
from a party, makes no sense at all in the morning. (Personal
experience, ahem.)</p>
<p>Thus it may make sense to start with a simple proof of concept, or
prototype implementation to verify the soundness of you idea, then
throw that away, and set up scaffolding, before you start writing
production code.</p>
<p>My latest personal project has a manual page, unit and integration
tests, Debian packaging, a CI project, and a home page. I can install
it and run it. It does't yet do anything useful. Before all this, I
wrote a prototype to prove the idea I had, and threw that away. Some
time this year I will start dropping in modules to actually do useful
stuff, and that'll be easy, since I won't need to worry about all the
boring bits. As soon as it does anything useful, I can also point
friends at a Debian package and ask them to try my latest masterpiece.</p>
<p>What's more, I have a better chance of getting them to help by writing
a module they need themselves, since they just need to write the
module and don't need to worry about the rest.</p>