Mess is just a mess

People tend to call mess a "challenge". That is seriously wrong in my opinion. Imagine you wake up after a party in your house — empty bottles everywhere, pizza boxes glued to ceiling, etcetera etcetera. Looking at all of this, what will you say? Will you ever say "what a challenge"? Well, if you will, you should consider visiting a doctor. "What a mess" a mentally healthy person would most probably say. So why would you call, say, thousand lines spaghetti code a "challenge"?

Mess is just a mess. Call it whatever you want but things won't change. You have to roll up sleeves and clean it. No challenges here — just a work that has to be done. The sooner — the better.

Release as late as possible, resist adding new features as long as possible

Recent issue in Mockito for Python made me seriously think on how I release and add features.

The story started the day I decided to add feature called "spying on real objects" to Mockito. Ideas was good so I quickly implemented it. Then, strangely, I got this feeling like I'm doing something wrong. I started thinking that maybe I am missing something, maybe I don't have all use cases covered by unit tests and so on. It quickly disappeared together with a cup of coffee and a cigarette. I quickly made new release, added documentation and uploaded version to repository. Done.

After two weeks, when I finally got time to look at mockito, I found a bug report regarding that same feature. And it turned out a really big issue. Not even an issue! The whole design of feature was wrong. The report even made think if adding that feature was really a good idea. As people started misunderstanding it and it made tiny API of mockito heavier. Gosh!

Today, understanding a fact that time machine is not yet invented, with a coffee and cigarette on a balcony, I made myself a promise: "release as late as possible and resist adding new features as long as possible". Funny thing that I actually knew it from all that nifty books. Hopefully, learning this lesson on my own mistake will imprint it in my brain forever.

Endotesting! That's it!

Last couple of weeks I'm constantly trying to sell Mockito to everybody around. I find it the only mocking^* framework for TTDing. However in discussions like EasyMock vs Mockito, expecting vs spying, strict vs nice and so on I was really missing good arguments. I could tell you many things about rigidity and fragility of tests, about maintainability and so on but a strong feeling that it's not all wasn't leaving me.

Today, when looking for a reason why expect-run-verify frameworks gained such a big popularity and what was driving them, I finally found that argument and it has a name - Endotesting. Read the paper, it's very interesting.

The intent of endotesting, and a solution called Mock Objects had a good intention. Those guys back at 2000's were facing issues with discovering bad indirect interactions in complex systems and they really needed a tool to find them fast. A tool that will fail at exact place where unwanted or improper interaction is met. Stack traces were invaluable, mock had to be strict as it could be the only way to discover unwanted operations on your objects or subsytems. The mock object they imagined(and yes, needed) is a kind of endoscope to find breakages in internal organs.

Hey! is this really the tool we need today? No, no and no. Problems we are solving with unit testing nowadays totally differ from those ten years ago. How hard is it to find a breakage in one to twenty LOC unit you're testing compared to complex ensemble of object interactions in systems written ten years back? Even more, in context of Test-First Development a breakage usually means that your code is simply not created yet or you messed around with assumptions; when your expected interaction under injected object doesn't happen you normally can find the issue in seconds.

Now it's time to answer yourself open and honest - do you really read stack traces of test failures that often? If you do - you're not writing your test before code, start doing it right now!

The thing I want to make clear, is that I do think concepts of Mock Objects and strict test are really important and usable, but on some higher level, say, Integration Testing.

^* Mockito isn't really a mocking framework but for simplicity we can call it so, right?

Mockito Python3k Port

Ported the python version of the best mocking framework to Python3000. Sources/Downloads are on github. Also available at Cheese Shop, of-course.

UPDATE: Mockitoes for 2.x and 3.x are now merged together. You can find latests sources on BitBucket. Many thanks to Distribute committers and Armin Ronacher for useful blog post.

Summary of this Year

This year is almost over and I'd like to summarize it a bit for myself. Since I promised myself to write only work-related stuff in this blog most of points below will be rather technical or such that relate to my professional activity.

Wins

• Started learning Python and Java.


• Tried my self as a coach, not really successful but it was definitely worth trying.


• Participated in programming contest which identified my weak places, the most relevant were standard algorithms and ADTs.


• Improved my knowledge of standard algorithms and ADTs. Many thanks to MIT OpenCourseWare.


• Improved my interviewing skills while interviewing couple dozens of PHP/Python engineer candidates at Lohika.


• Met two great guys, Denys and Anton, whom I had many enjoyable programming evenings with. I learned a lot from them in both professional and personal meaning. Thank you guys!

Fails

• Tried myself as TeamLead for quite a short time. However long enough to see that I don't see myself a good TeamLead (or any other kind of manager) in future. I'm techie. Period.


• Started many in-house projects with my friends and never finished any of them. Looking back at those I see that we normally gave up with them mostly after the technically most interesting part was done.


• 26 (for today) drafts of blog posts never finished.

Plans for Next Year

• The biggest plan for next year is to change a job. I like my current, but I'm working as outsourced contractor, which has way too many disadvantages.


• Continue learning Java, maybe even get some certification like SCJP.


• Continue Improving coaching and presenting skills.


• Continue blogging. I find it pretty interesting and a nice way to systemize and share knowledge.


• Finally finish at least one or two in-house projects.


• Become a TechLead at Lohika. Will let me participate in new interesting projects.


• Improve my English.

Those are not all, but most important points from top of my head. Should be fun to go through this list next End of Year.
Cheers.

Python: Function Argument Default Value Gotcha

Nothing new for experienced python developers, but really annoying for beginners. Try this piece of code:


The output of this will be:


Dude, what just happened? See, python calculates function arguments' default values on function definition time. So our default argument list is actually a reference that never changes. Hence we always modify same variable when calling append with default list.
Even knowing the pythons execution model this is one of those things that can cause what I call a "sweet wtf moment" and make you start a debugger. Which you of course hate doing cause you're TDDing, right? :)

Workaround? Sure:


More info in Python Manual.



Download source code of examples in this post.

Agile Blog Post

This is an Agile Blog Post. I started with the Simplest Thing That Could Possibly Work.

This is the end of Agile Blog Post.