Maybe we should add motors to these desk chairs ;–)
Maybe we should add motors to these desk chairs ;–)
As said Tom Cargill
The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.
By extrapolation, this would mean that every time we increase the requirements by 10%, we need to double the total development time ! That would mean that solution complexity is an exponential function of the complexity of the problem.
That could explain why techniques that work well for small problems don’t work well at all for large problems, and vice et versa. For example
|In the small (think one page script)||In the large (think multi millions lines system)|
|Dynamic typing||Static typing|
|Imperative style||Declarative style|
|Manual memory management||Garbage collection|
|Shared memory||Message passing|
Just for fun, let’s suppose that we could deduce a unique constant C for every language such that
Here is a plot of this formula with different values of C (0.5, 1 and 2)
We can see that small values of C are best for small problems, whereas greater values are evolve better with larger problems. For a given problem, there is quite a difference in the solution complexity, if the formula was true, and that we knew in which zone of complexity our problem will always be, we could choose the appropriate technology ! Experienced engineers already have the gut knowledge about how to chose the right tool for the job !
That’s not all, let’s have a bird’s eye view of the same formulas
I increased the maximum problem complexity by a factor of 3, I had to multiply the solution complexity by 100 ! In the end, these exponential curves all seem frighteningly vertical. This could explain why the divide and conquer approach works so well in software : 2ex < e2x. Abstract and powerful APIs might be our best weapon against complexity.
People behaviour does not match this exponential hypothesis though :
This leads to more interesting questions :
At the moment, I am exploring the world of SEO, and so I thought I could start with my blog. I found SEO for Octopress websites that I followed to add keywords and descriptions to this blog.
To fill actual keywords for all my existing posts, I had 2 options :
Sorry, I chose the geeky solution …
Just add this code to your toplevel Rakefile, and run
bundle exec rake add_keywords and keywords will be added to your existing posts.
I love writing automated tests … or rather, I hate having to work in untested code. I find it makes my life unnecessarily stressful. On the other hand, the cost of maintaining badly written tests can sometimes outweigh their benefits. This is usually the moment where the team resorts to manual testing, and gets back to the ways of ‘the good old days’. Personally, I don’t like the good old days when we had to stay up all night
to add even more mess to fix something for an important deadline.
Here is how I try to make my tests as maintainable as possible :
All in all there is nothing new here. A lot of things come from GOOS others from Clean Code, the mocking ‘requirements’ come from an article from Gregory Brown, I found others from my own experience and from a lot of other sources I cannot remember now …
Happy testing !
Since I decided to stop Mes Courses to focus on AgileAvatars, I have been extracting open source gems from the code base. The last one is Storexplore : a declarative scrapping DSL that lets one define directory like apis to an online store.
As explained in the Readme, it allows one to declare a store this way :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
And to use it like that :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
I tried my best to make this library high quality :
Let’s hope it will be usefull for some.
I really don’t know why Scrum Sprints are called sprints ! From my experience, the number one mistake made by team starting with Scrum is to work as quickly and dirty as possible to complete the sprint, forgetting the sustainable pace.
Finding another word is difficult though, I thought of ‘stage’ or ‘milestone’ that both convey the long run idea, but both feel more content than time bounded. A more exotic word could be a ‘Scrum push’, it conveys slow and intense action action rather than quick results.
Overall, the traditional agile ‘iteration’ is not bad at all, at least a lot better than Sprint.
The ‘Quick and Dirty’ Sprint strategy, is like trying to win a marathon with a greedy algorithm:
1 2 3
Not likely to work … Marathoners know that they’ve got to stick to a constant speed during the whole race in order to finish it. The way to get faster is to :
Is there something to learn from this to improve software development speed ?
A few days ago, a colleague currently taking the coursera course about reactive programming in scala, asked me to explain him what monads are. It’s always a tough question, and I rarely manage to give un understandable answer simply. This time though, I kind of managed to pass him some understanding of monads :
I thought it might be a good subject for a java kata ! This is what I tried to do in java-monads-kata. Here is some sample monadic code from the kata itself :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
You can have a look at all the final code, or go through the whole history to get the ‘kata’ feeling. It’s a shame Github does not offer a nice chronological repo history slideshow, for better experience, I recommend that you use Chrome with Github improved : this allows to view diffs right from the Github history.
The resulting code is still quite far from a Haskell monad :
I’d love to hear some feedback about it.
We are using Scrum at work. As an eXtreme Programmer to the bones, I wanted more collective code ownsership. We were already doing some pair programming from time to time, but I thought it might be a good time to try public code reviews.
I have already been doing code reviews in other jobs, but the experience has been disappointing up till now for the following reasons :
Public reviews, as discribed by Karl Fogel in Producing Free Open Source Software on the other hand seem something great to encourage share and peer review. The principles are simple :
At work, we are using Perforce and Code Collaborator as a review tool. We did not have the possibility to send an email at every perforce submit, and manually creating code collaborator reviews for every change is a chore. I spent an afternoon writing a small ruby script that polls perforce for new changes, and automaticaly creates reviews in Code Collaborator from these. I also added something to spot existing Jira ids in commit messages, to enlarge the existing review instead of creating a new one for every commit.
We are very pleased with the result, all the team is participating to the reviews. As with all good code reviews, it’s helps :
Here are the general goals I had when using the rails asset pipeline :
So, here is how I eventually organized my js code :
1 2 3
1 2 3
1 2 3 4 5 6
And you, how are you organizing your javacript assets ?
A software team is now using Scrum and AgileAvatars.com magnets in their daily work ! A few days ago, I sold my first lot of agile magnets. These customers were ready to experiment and iterate, and after trying some things that did not work so well, we came to a great result :
I did not yet build any automatic order site or app, but I can now ship magnets for real though ! Don’t hesitate to contact me through my email or the contact form on AgileAvatars.com if ever you want more !