Archive for the ‘Working smart’ Category
This is what popped up while going through a thought experiment on choosing hosting and provisioning for the development of a new Software as a Service offering.
The options considered are:
- PaaS with multi-tenancy – use a PaaS offering (think Cloud Foundry, Heroku, Google App Engine and Windows Azure Compute) to host a multi-tenant system. Provisioning for a new client is zero-cost done inside the system
- PaaS with one environment per client – use a PaaS offering (think Cloud Foundry, Heroku, Google App Engine and Windows Azure Compute) to host a regularly developed system. Provisioning for a new client means configuring a new PaaS environment, adding an instance and deploying
- IaaS with multi-tenancy – use an IaaS offering (think Amazon EC2 or Windows Azure Virtual Machines) to run a stack of Virtual Machines configured to run your platform of choice, hosting a clustered multi-tenant application. Provisioning is zero-cost after initial setup
- IaaS with one stack per client – use an IaaS offering (think Amazon EC2 or Windows Azure Virtual Machines) to run one stack of Virtual Machines configured to run your platform of choice, hosting a clustered (or not) regularly developed application for each client. Provisioning means creating stacks, adding virtual machines, installing OS, DB, platform and deploying application
For convenience I also added a category called UGLY, just to highlight what I consider to be the worst point of each option.
Over PaaS with multi-tenancy
Over PaaS with one environment per client
Over IaaS with multi-tenancy
Over IaaS with one stack per client
Some points are good and bad simultaneously. Examples:
Application must comply with platform constraints – which means that you can’t always do what you want to do, producing
- GOOD – sometimes enforces good coding and resource-usage conventions
- BAD – more effort in developing exotic things
One version for all clients – there can only be one version in production
- GOOD – less versions to worry about, less things to manage
- BAD – you may upgrade users that want the old version or you may have some users that want deep customizations and that are willing to pay for them
The overall conclusion is that the higher you go, the less you have to manage, the cheaper it gets.
For another good read you can check out the PaaS vs IaaS comparison on http://www.engineyard.com/paas-vs-iaas.
I refuse to answer that question on the grounds that I don’t know the answer.
- Douglas Adams
When asking somebody a question, assuming that they are even listening, you can expect them to either:
- know the answer
- don’t know what you’re talking about
If they know the answer they’re going to give it to you right away, and that’s fine… because they know what they’re talking about.
If they’re in the clueless gang, they’re either going to give you a “sort of correct in their own opinion” answer or they’re going to recognize the fact that they don’t know, honestly. I just hate it when people give me “their correct answer”… and I’m not the only one.
Most people don’t realize that the choice they make in that exact instance is a make it or break it deal, especially if it’s a first impression.
Appearances do matter, and somebody jumping directly to conclusions even if their knowledge of the situation or problem at hand is close to nothing will automatically get tagged as either “clueless” or just plain stupid.
On the other hand, being thorough and wanting to give the correct answer (not the first one) is highly prized, because… it’s more productive to work on facts rather than fantasy.
So, if somebody asks you a question that you should be able to answer but you can’t:
- honestly say that you can’t answer at this time and that you’ll get back to them in a very short time
- find the right answer and validate it – if you’re going to take your time, make sure that you are right
- get back to them as quickly as possible - never over-promise and under-deliver
This is really important for anything related to costs (such as licensing issues and estimates), compatibility or interoperability questions (most of them are tricky anyway) and client-facing issue.
Ensuring that your answers are correct and that you had time to think things through will help you do your job better and I’ve never seen a manager say “I don’t want the right answer in 10 minutes, I want the wrong one now!”.
So don’t just get things done, start getting things right.
I know it’s really difficult to say no and that you just accept things because of your inner fear of conflict and lost opportunities. You just have to get over it and just learn once and for all how to say no! You’ll do yourself a favor… and everybody else.
The next time your boss (or anybody) is trying to push down an extra task on you just say “I’m sorry but I can’t do this right now.” in a straight and non-defensive manner. In time, learning how to say no will let you focus on the tasks at hand and it will change the habits of the people you work with – they’ll be more picky about the tasks they delegate to you.
If they ask for an explanation just say the truth – that your schedule is already full and that another task will just lower the quality of your work along with actually delaying your already existing tasks.
If they don’t understand “loss of quality” and “delay”… well, it’s their problem.
Quality is a rare commodity these days and we have to fight for it, even if it may hurt some feelings or even if it pisses some people off. In the end, quality always wins.
Users are strange creatures, and to demonstrate, here are some quick facts:
- They want to achieve lots of things as fast as they can, without learning anything new;
- They hate reading and avoid anything that resembles help or a user manual… or even freaking text boxes;
- They want user interfaces that look like other user interfaces and that function the way that other applications function but that ultimately achieve a different goal;
- They want things to just work.
Yup, strange creatures indeed. Who would have thought? Not us programmer types anyway.
None of these facts are new. All of them are known since the dark ages of computing. All of them are well documented and repeatedly demonstrated. It just seems that a lot of the things that we used to know and follow are now forgotten.
Users want well designed products that are tailored to their needs and that help them do what they want to do. Users just don’t want to read the manual and they have chronic dialog box blindness. For users, the user interface is the product so if you want them to use your product they need consistent and usable interfaces. Users need professionally designed, developed and production-ready products that just work; not unfinished, buggy, wanna-be software.
Because users are ultimately our customers and because it is the right thing to do if we consider ourselves professionals that is what we must provide. Because that is what they deserve.
You can consider this post a small rant – just blowing off some steam after re-iterating some of these facts to a bunch of confused developers that think users are just plain stupid. They’re not stupid – we are just building software for the wrong people (rocket scientists that can read binary while unit testing in their sleep).
It’s really hard to create beautiful and clean web interfaces when you have to slice and dice images for every little button, action or highlight. Well, now you can replace them with web-font characters styled with CSS3 – as most browsers have support for them.
Here’s a sample from something I’m working on just to give you a feel:
Wait, there’s more: using styled glyphs instead of images gives you more flexibility with application themes – and less images to mess with:
The nice thing? What you’re actually seeing above is :
<div id="header-toolbox"> <a href="">c</a> <a href="">U</a> <a href="">S</a> <a href="">X</a> </div>
The font that I’m using for the glyphs is Web Symbols, available from http://www.justbenicestudio.com/studio/websymbols/
You should be already used to my religious prototyping habits – I tend to try out a lot of stuff, build a lot of things that I later discard and so on.
Knowing that I do this a lot, I tend to actively look for tools that are either very easy to set up or that don’t even have an install footprint. Last year (I think) I found Mongoose, and used it to replace my normal prototyping instance – an Apache instance that I had running all the time on my dev machine.
Mongoose turned out to be the best choice, being just an executable (small – in the hundreds of kilo range) that you can run to get an instant web server, serving files from any folder.
Well, tonight I got my revenge. I needed some dynamic calls to test a RESTful API, and because my API builder is not ready yet I had to resort to some fast PHP hacking.
As my new home dev machine is not fully configured yet and I had no Apache installed and configured I thought what the hell, how’s about trying to hook up the Mongoose CGI. I knew it had support for it but I never tried it before, until now.
So, without further a due, I present the fastest setup for a prototyping web stack (on Windows) ever:
1. Create a folder – duh
2. Get the latest Mongoose binary from http://code.google.com/p/mongoose/downloads/list and copy it to the folder
3. Get the latest PHP zip distribution from http://windows.php.net/download/, unzip it and copy the php support files for CGI to the folder (php-cgi.exe, php5.dll and php.ini are enough)
4. Create a mongoose.conf file with the following lines:
listening_ports 80 document_root . cgi_pattern **.php$ cgi_interpreter .\php-cgi.exe
5. Run the Mongoose binary (I usually rename mine to mng.exe) and access it with your favorite browser
And that’s it, you now have a web server and PHP configured, all under 5 minutes. Enjoy!
You should only use this for prototyping stuff – NOT FOR ANYTHING SERIOUS LIKE A PRODUCTION OR CLIENT-ACCESSIBLE INSTANCE!
“People don’t buy WHAT you do, they buy WHY you do it! And what you do simply serves as a proof of what you believe!”
If I could say it better I would, but I can’t so here is the TED clip.
Objectives help your team to focus on the tasks at hand while not losing sight of the overall outcome that it needs to reach.
A good team is results-oriented, focusing on what it is trying to achieve not what it’s currently doing.
Use this checklist to verify that the objectives defined for your project will help you achieve results and won’t hinder your efforts.
Are the defined objectives clear enough?
Contrary to goals, objectives must be focused and clear. Understandable objectives will drive the team to successful results.
Are the defined objectives SMART?
Do the objectives comply with the SMART criteria:
- Time constrained
Is the number of objectives right (4-6 range)?
There is no right number of project objectives but taking into account the fact that objectives should be known and tracked by the team, a low number (having between 4 and 6 objectives is a good compromise) will make it easier for the team to keep focused on the essential. Remember, the more objectives you have, the harder it will be for your team to keep track of them.
Is there a known and clear context?
The defined objectives must be linked to the overall context. Objectives that do not advance the project (useless objectives) or that are contrary to company strategy (like building a whole new product that competes with one that already exists) should be eliminated or changed. For each objective yourself these questions:
Will achieving this objective advance the project?
Does this objective tie in to the project and company goals?
Does this objective follow the company strategy?
Are the defined objectives known and agreed upon?
It is important that all stakeholders know and agree to the defined objectives. It is very important for project success that the objectives are known and agreed upon by project sponsors and executives.
Can each defined objective be tied to a deliverable?
Think of this as a post-SMART check. If you can pinpoint at least one deliverable that helps you attain an objective you are OK. If you can’t ask yourself this: how are we achieving this objective? If it doesn’t matter, you should remove it from the list.
Does every defined objective have quality criteria specified?
Besides being measurable, each objective should have quality criteria defined, so that both quantitative (are we there yet?) and qualitative (is it the right thing?) parameters can be tracked and accounted for. Getting it right is just as important as getting it done.
I live my life following a simple set of rules:
- Measure twice, cut once
- Change is normal, expect and embrace it
- Hope for the best but expect the worst
- The quality of the end result is never an accident, it is always the result of intelligent choices and hard work
I apply these rules to everything I can, starting with preparing and following a simple shopping list, small home projects and ending with my day to day job.
Here’s the simplest and most intuitive example: my new photo wall, which I had to build in the week that my wife was on a business trip.
- Define the outcome – I wanted a photo wall built with happy colored frames and pictures of my family that would fit in the hallway between my bedrooms – this took about five minutes;
- Analyze the location and identify the materials – I knew what I wanted so I searched for photo frames of different proportional sizes and happy colors and I selected the pictures from my photo collection (pictures chosen out of roughly 34GB of previously filtered photos). I also measured the hallway and calculated my constraints – this took about three days;
- Design the product – I built an Excel simulation of my photo wall where I laid out different frames of different sizes and colors and placed different pictures until I got the mix right;
- Test the design – I placed the photos in the photo frames and laid them out on the floor in the exact pattern. I isolated the ones that I did not like (color combination was wrong, photo did not fit in the overall picture, etc.)
- Modify design based on test feedback;
- Implement the design.
- I knew that I will surely select pictures that I won’t like – so instead of choosing only the 10 pictures I used in the simulation, printing them and getting it wrong (which would have made me miss my deadline) I selected and printed about 20 pictures of various sizes;
- I knew that I will surely change my mind about what will the color placing will be when I tested the design – so I bought 50% more photo frames of various colors;
- I knew I would mess up the positioning of the photos, even if I used rulers and drew lines on the wall – so I bought double adhesive tape that would only dry after 5 minutes, leaving me a change to unglue the pictures and straighten them
Change is good
Why expecting change and embracing it is a good thing:
Design – this is how my simulation looked like:
While I worked on it I really liked the feel and loved the layout and coloring.
I went on to testing.
The test and implementing the feedback – this is how my layout changed after the test:
As you can see, I changed two pictures (both content and frame color) – that’s a 20% change from the original design but an overall improvement in the color balance and the overall aspect.
The result – this is how the final setup looks like:
Now isn’t that nice?
I actually finished an hour and a half before my deadline and had time to prepare and place 4 more photo frames around the house – nothing is lost, everything is used J
I try to learn from everything I do and my lessons here were once again:
- Measure, analyze, prepare – then prepare some more;
- Expect and embrace change – change is good for you, actively look for it;
- Expect the unexpected – prepare for it;
- Effort and determination pay off in the quality of the end result.
I KEEP six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.
In Prototyping the web API I started describing an idea to build a tool that can be used to try out/prototype web APIs before actually building a back-end implementation, helping a team to describe a clear and strict HTTP API, as well as allowing them to build and test client code without having written one line of server-side code.
This post is taking those ideas further, trying to crystallize the concept, objectives, goals and my overall expectations of this tool.
Based on my previous attempts at crudely building a harness for my web development habits, I’ve outlined a sort of a wishlist.
Apis, as I’ve so naively chosen to name this tool will be a part of my typical development stack and must:
- Have a pleasant, easy to use interface where I can define the desired HTTP API, including endpoints, request and response configuration that I can export as a well-structured definition document;
- Allow me to save the definition in a human readable and human editable format that can also be saved, compared and merged in a VCS;
- Allow me to define standard responses for each API endpoint based on the request configuration so I can test the API, build a proof-of-concept API and even build a whole user interface decoupled from back-end services;
- Be standalone and packaged in an easy-to-use installer so I can send it to my fellow developers that can load the API definition from VCS and work on it.
That’s about it. If it seems pretty simple, it’s because most useful things are, and should be…. simple.
This is a simple one:
- I like a well-defined, clear and strict web API in my projects. I want others to want one too;
- I like to prototype a lot. I want to be able to quickly prototype a web interface without having to set up a web server or -hell no- a full development environment. I want to make it easier for others to prototype;
- I want to test my decoupled web clients in a clean, well-known state and I want my server-side code to have no idea who they’re talking to.
This is a simple one too:
- Not like I did before. I want a desktop app, not a whole bunch of code, glue and configuration files;
- I want to build it clean, so I can easily extend it. I don’t really care about other operating systems than Windows so I’ll build a Windows desktop app;
- No bloody way I am building it in some scripting language again and I code Java professionally so I don’t want to do it in my spare time. Plus, I really like C#, the .Net stack and WPF;
- I’ll build it in my own time, build it right, and build it for myself (for a change).
So, Windows, C#, WPF, VS Express and a whole lot of will power it is!
I’ll build it iteratively and story-based. I won’t say agile because well, for an agile process treating communication and people problems… let’s say that you need a minimum of two people for hate or love.
When, Where and Who?
There’s no better time than now and no better place than wherever I am. The Buddhists say it well “Wherever I am, I am home, I am now, I am free”.
I’ll start building it alone. I know it’s not a good idea to work alone, that in programming, one is the loneliest number but later on, if it catches on, I’ll try to get some other people on board.
I’ll host everything on gp… it’s been lonely since the migration to WordPress.
That’s it for now. I was storing this in my brain, which is stupid… that’s why I have a blog.