Light Table – a real work surface

It started with video about intentional programming or interfaces. It is a very impressive demo. Then Chris Granger went on to create a demo of his own in 2012 and start a Kickstarter project to support creation of open source ide. What he created is a fun environment, not as ground shattering as we were led to believe, but still great place to have fun while programming. In the end, as his interests moved on, he published everything on github where it still have some development, but I believe it kind of died down for now mostly.

Screen Shot 2015-02-02 at 10.46.36 PM

I decided to try it out few months ago and had a lot of fun. I am not as adept in Clojure but in Javascript you still can have fun with it. There are number of modern features, workspace with fuzzy logic search for filenames for example, but I would say the most interesting one is instant repl, which allows you to execute any line as you write it. This really has to be experienced, more then anything, because it does help and shortens development path. There is also ability to have synchronized preview window on the right (you can have it anywhere) for web apps, that would spin instance of the app and offer preview.

Also, it would be a disservice not to mention large number of plugins available that provide support for most languages and formats.

As a development environment, I can’t say I could use it exclusively, but it is fun to use for occasional project and it does have productivity enhancements. Where I could see it would be useful is in workshop setting where groups are provided training, so instant execution and visibility of variable values would be of most use.


Celebrating Failure is Wrong

Enterpreneurs, especially wanna-be ones, as well as first time startup hot heads often will promote this as a way of encouraging themselves in the face of failure: “It is OK to fail, we learned a lot”

If you are doing a startup, or starting any business, you want to succeed and you want that badly. Also, you should learn everything possible to make this true. It will never and I will repeat this, It WILL NEVER BE OK TO FAIL. You will fail and you should pick it up and try again, but you should never think that it is OK to fail.

Steve Blank and Eric Ries don’t say that it is OK to fail, on the contrary, they want you to use systemic process in order for you not to fail. Being organized and having systems in place, kind of going back to my previous posts about ActionMethod and Behance, these things are super important to get you to a point of success.

Don’t be fooled, even with all their wisdom you and I will fail, a lot. I learned to embrace the risk over the years, this doesn’t mean I will ever think it is OK to fail. And you know what, if I am doing it with my own money and time, it can be OK. If I take moneyz from other people… well, I am failing myself and I am failing them.

Richard Bandler would say, thank you but I pick to be successful, let other people fail.

It is never OK, it is time and effort wasted. If you see that your project is not going the way it should, do your best, but cut your losses if things don’t go well.

Anyhow I felt a need to ge tthis off my chest.

Only good way to develop apps II

I would like to clarify some of the points I made in my previous post. It might sounds that any app has to be developed in 2-3 days by single guy. Kind of, it does.

# About time

What you are doing is that initial development is really in short period of time, like before mentioned 2-3 days. Now, some apps are simply more complex and have a lot of small quirks. Then you develop skeleton app and work on details in next month or two.

I am not really a big fan of projects that require 6 months. Six months in internet time is huge. I prefer things that can be made faster. Also, this is very intense work, you will not be able to sustain it for more then a week and 2-3 days is optimal.

After initial development, then a lot of time can be spent doing a/b testing, adding meat to the bones of skeleton app.

For most webapps, initial timeline is all it is needed.. Games as a rule need 2-3 months at least, or that is impression I got. Anything else, corporate software, can be done faster, but due to corporate bureaucracy, most likely will take very long time and cost a lot of money.

Again, this is a good way to develop apps for startups.

The only good way to develop applications

Only good way to develop apps is through focused effort of a single or small team of developers.

Agile software development practices

There are a lot of thinking going on how to organize development of software. There are some really cool methods and methodologies that came out as a result of this thinking and observing succesful software projects. I’ve been fan of agile software development practices for a long time. I wondered how come this beautiful and clever methodology is not giving results or not giving nearly as great results as it should.


There are organizations that expended quite an effort to implement agile methodologies, they hire what I like to call ‘overpriced consultants’ (like me) to help them. We all work hard and our efforts are honest, yet, results are mixed.
When you point this out to proponents of agile methodologies, they just wave their hand and say that process was not fully understood or properly practiced. I would say that any process that requires such deep understanding, and honestly agile and scrum are as simple as can be, is not worth knowing.
This is not to say that those processes are not bringing results, project on which I am currently working was created by consultants of ThoughtWorks in three months. Usually sites like those would take longer to create in corporate structure, so obviously agile does bring significant savings and those consultants are totally worth their rates.

One true way to get results

Now, what is the one true way to get results?
Very simple, if you are developer think about the time when you cranked out app in really short time, or if you are not, look at success stories of startups, you are bound to hear that founder(s) hunkered down for a weekend to krank out initial version, or alternatively that they spent a week or two developing it.
My personal experience is that when you have an idea, you get a rush of excitement over it, you sit down and code, code, code. You don’t sleep, you eat a little, drink a lot of coffee, you have everything in your head, things are coming into place and you are shaping your app… this is one awesome experience and  you get your app developed in a weekend or prolonged weekend (3-4 days) or a week, not much longer. Well, you couldn’t stand this longer anyway.

Why is this a good way to do software development

I think reason why this is such a good way to do it is mostly in focused effort on production level code. For development to happen, it really needs a lot of information to be present in developers head, since we are talking about one to three, mostly guys, working in great synergy, they don’t spend too much time on anything else and can just focus on ‘production level code development’. Since all it matters are code that goes to production and this way you are trimming everything that is not production code, like: planning, meetings, coordination, discussions on standards etc. in order to get that level of code. Now you will of course do planning, but it will be leanest planning on the planet. And of course this way you are outproducing any big corporation, agency or consultancy that offers software development.
Many people don’t understand this and keep asking for larger teams when you can do this with single developer or developer/designer pair.

Where can I use this

This of course can’t be easily replicated in corporations because they have… well they want to see their employees present at their desks etc. Plus this is very intense way of development.
This is the way startups should develop their software and this is how initially they create value.

In the end, I mostly wrote this to remind myself of glorious times when I did exactly this with great results.

Prototyping applications

I am big proponent and fan of prototyping apps before they are built, I find this practice helps a great deal focus project, shorten time, increase quality of the code and ensure all participants have more fun in the process.

So benefits are:

  • Focus on the problem
  • Shorter development time
  • Fun for participants
  • Higher quality of codebase and application

As a rule, prototyping should be done by any tool that you are comfortable with, however obviously some are better then others.

While some people will use Balsamiq for prototyping, and it is legitimate tool, as a developer I prefer to have clickable prototype. A lot improved in the meantime, in terms of tools that are available. In the past, I would start prototyping using html and usually grid framework like BluePrint or . This was great, however now things are even better today thanks to several new developments.

Let’s first quickly cover the process. Prototype development starts with basic requirements, then pages are built, shown to customer/client who is available to give quick feedback, which is then rapidly applied and cycle is repeated. That way, a lot of flaws and inconsistencies can be discovered earlier then when you already spend 1000 dolars on development. Side benefit is that development of such application is also significantly easier because everything is clear, and you already get all the forms with names etc.

Now let’s talk about tools used. There is a lot of excitement over release of Twitter Bootstrap, a set of styles and javascript behaviours that you can include in your app to get you started. This is obviously fantastic tool for prototyping, but things got much better then that. Not only that we have Twitter Bootstrap, there are few others that are as good and worth mentioning.

Before you start prototyping, you should have simple way to play with your prototype. I find John Long’s Serve to perform great for such purpose, it is built for ruby projects, you can use haml, sass and coffeescript, all the good stuff.

So before you start, install Serve and start your project ‘like a Bos!’

Then pick your poison, there is Twitter Bootstrap with it’s styling to aid you to assemble your pages and flow:

However, there are also other options. One really good is Skeleton, framework whose goal was to make your app look good both in browser and on mobile device, as of lately Bootstrap is doing that as well, Skeleton is probably a tiny bit better still at it and overall is very clean choice for prototyping, Bootstrap sites all look alike.

Latest choice that I became aware recently is Foundation CSS. It is solid framework made specifically for rapid prototyping.

So, these are some essential tools to use for prototyping. Having a set of common defaults help a great deal when you are thinking about what will application do, not how it will do it. Things looking good, also help a great deal.

So now that you learned about these fantastic tools, let’s get prototyping!

Getting control over your time and inbox

So, it’s been a while since I wrote, a lot of things happened. Often I started a blog post but didn’t post it. Here is one that I think it will be useful.

My inbox has been at zero in last probably 7 years, it is a habit that when I learned, I just kept it and I don’t really have to think about it much any more. I am surprised when I read tweets and posts about otherwise capable people, struggling with getting inbox to zero. And on top of that I never did that email bankrupcu thing that some people do when they erase emails for them. If you sent me, I read it, or not, but I sure don’t miss it accidentally (happened rarely, few times).

I will explain how to get there simply and easily, this is simple way to get more productive and efficient, feel better and communicate better.

So, how do you get your inbox there?
Very simply, take a deep breath and decide to do it. You don’t even have to do everything in the same day, if you really get a ton of emails, but decide.
Then create folder ‘past inbox’. Move all of your emails there, just select all and move. From that moment on, you will decide about every email that comes to you.
Next step is to start from the top of past inbox pile and decide about emails. You will do following things with it:
* respond to it (you can create folder action and move it there, I respond it right away)
* decide this is something you don’t need, VERY IMPORTANT, don’t just delete it, if it is a newsletter make sure you click and unsubscribe. From now on, any newsletter, mailing that you don’t really have time to read, can find info online etc, click on unsubscribe and then delete.
This way you will save yourself work in the future.
* any regular mailings that you receive but really don’t need your immediate attention, just filter into appropriate folder. Being wise there is of utmost importance.
I love getting sales info from NewEgg and like, however every sale newsletter from them goes to newsletters/sale folder. I can find them whenever I need them
* shopping notices go to shopping folder, account creating emails go to account folder, facebook updates go to facebook folder (which I rarely check).
* If you have server monitoring and think that you need to see those emails, it is fine, I would still filter them into folder but check it, however, for some finance related stuff, I just make filter that would mark it with appropriate label, but will leave them in my inbox. That way I can take a look and then just archive them.
* Delete a lot, most of information that is coming to your inbox can be easily found online, unsubscribe whenever you can.
* project based, client based emails, make filters for people you corespond to label them, then if you see something you want to respond later, you can just archive them and check them later. No need to do anything more then once that can be automated.

Now that I made my inbox clean, I don’t really check it that often, no need, rarely emails are that important. But when I do, there is never too much and it is easy to respond.

One more thing I noticed, if you don’t like something, if client is unreasonable or plain silly, put that email aside and respond in 30 mins.

Hope I made you productive, I already am.

Zeljko Dakic

Software Craftsmanship

There seems to be much interest in steering software development away from rigid planning and engineering methods as it was tried in the past and more towards a craft and discipline that is not that much precise and predictable and is more indirectly controlled. This year in Chicago we will have a conference on Software Craftsmanship, with Robert Martin as leading speaker. There is a manifesto .  And my immediate excuse to write this post is article by Jeff Atwood at Coding Horror:’Software Engineering: Dead?’, which in turn references this article by Tom DeMarco.

It seems that we came to a point to realize that software development process even though it does look like engineering, it is more similar to some other disciplines and that current metaphors we use are not adequate to describe it. I am not sure how far software craftsmanship will go, it is certainly a valuable concept and idea. It moves process of creating software away from McDonalds analogy where every little step will be well defined and even if you are dumb, you just have to follow steps and you would be good. This never worked well with software and failure and exorbitant price of outsourcing projects to far-away places like India are proof of that.

So one trend is moving away from well defined practices in development of software. On the other hand, new practices, that are represented by agile methods of development are coming into view. They require that developers who work, even though they have to follow very specific and well defined process and steps, they need to be well versed in development of the software, semi-educated, copy and paste developers just can’t do this (or didn’t figure out how to do this at the moment).

I think it is good that we are rethinking how to develop software and what are optimal ways. Generally I am all for agile practices, I think they are liberating in many ways and bring quality to software development. They also are not without craziness, like when it is expected that project sponsors start and finance project without any idea about time and cost. Unfortunately this is one of the agile ‘values’. But another time about crazy side.

I am happy to see software development maturing into profession, that can be distinguished by tools, techniques and methods people are using, which has still long way to go.  But then, if it was a well defined profession like medicine, who knows if it would be this fun to work, if you already have rigid set of rules and procedures.