the necessity of software design

when designing software many aspects come into play and design plays an important role as part of the decisions made at the product level. there is a balance between effort and flexibility that is sometimes linear: quick and simple will hit a wall at some point and will most probably will not scale nor will it be easy to change key features and/or layout. these design decisions extend well beyond a choice for the right MVC backend and frontend framework, nor does it apply to the choice of the data warehouse and wether it should be relational or pure noSQL or a hybrid.

as a product one builds starts having more users interact with it and data is accumulated – requirements change and evolve constantly. staying agile in that respect makes sense, especially in the initial startup phase. in general, issues that may come up can be mitigated if the product is well designed. like everything else in the world software, there is a delicate, zen like balance between effort and efficiency.

dude where is my code?

so the users LOVE the right side bar and would like to add a couple of more navigation items. awesome. hmm… which file is that menu created? let me quickly consult with the guy who coded it… oh wait, he is no longer with the company… you know what, i can easily start the debugger and move about the code until i see something that makes sense… common practice? probably. efficient? certainly not. rule of thumb is, that it should be obvious as daylight where changes should be made and everyone maintain these rules, otherwise things get so messy that the most simple improvements are a pain. good code organization and well documented methodologies that are taught to the team and well explained are an important step

context and boundaries

so you have found the code segment where you think the changes should live. great.  before you refactor it , answer this question: are you clear on what this code is suppose to do? the expected input and output? is it clear what the code is NOT suppose to do? each code segment should live on it’s own, unit testing and all, where it’s very clear what this method is aimed to achieve. no guessing.

software fragility

nir i’ll be happy to take care of that ticket. just know that if i change that controller the other view will break and we’ll have to take care of that and then there’s this other controller… unfortunately it’s common to see software break incredibly with minor changes (especially frontend). this is why both unit and functional testing are critical, but that’s for another post.

development scalability

when one developer’s code commit breaks one function, ideally it will not impact other developers who are working on other regions of the code. ideally code integrations will include less merge conflicts and will be resolved smoothly. this is one good reason to switch to git if you haven’t done so yet.


updating your product maybe a very delicate process, especially if the model changes and you need to update the current schema and still be backward compatible to hold the current data sets for a live target.  now consider your product is white labeled to 50 customers where different version of the products are deployed to different servers, and ideally you may require to roll back or quickly update critical bugs. the complexity of maintaining these machines grows exponentially without a proper deployment strategy.


this is one important metric to wrap your heads around and be able to benchmark your team. as you build your system what is the effort required to add this specific feature? is the investment linear in terms of time and capital? does good design help people be more productive?


as the system grows the requirements will change because you get good feedback from your end users and what you thought you knew a year ago has not turned obsolete. supporting multiple and different code bases, the requirement for higher availability, redundancy, better performance and backward compatibility are all requirements that come down the pipe as your platform and client base grows.

some final thoughts… when it comes to design we now know that some prior planning and careful thinking can go a long way.

the bottom line is that the product owner needs to stay focused on what the business requirements are. the product should only solve the problems it is designed to solve so the time dedicated to development is better spent.



scrum 101

scrumscrum methodology is quite popular and i’d like to dedicate this post to making some sense out of it for those of you who are not familiar with it. if you are a development team, scrum could be an interesting fit for you or at the very minimum something new to consider and evaluate.

scrum is a software development methodology that works along the lines of lean manufacturing or agile. to make sure we all speak the same language, agile is lean is scrum in a superficial or high level view point. if you are wondering on the origin of the name, scrum is borrowed from rugby where the players lock up and try to get a hold of the ball by passing it with their feet. small iterations. makes sense?

the methodology assists in defining the development life cycle and stages, the key players and roles and how responsibility is delegated. scrum also assists in figuring out how to stay on top of project and it’s progress, how to address and perform changes/enhancements to the development plan and how to deal with risks. taking a step forward, scrum can help lead development teams, be engaged in drawing conclusions and improve both product and process on regular basis.

if you were a scrum, the world is roughly divided into you and waterfall. “you” means agile methodologies such as kanban and XP. waterfall is a more sequential approach from the 70s that was (probably) influenced by traditional manufacturing, and is similar to the approach of building a house:

  • there are restrictions on the order of operations (one cannot lay the roof before foundation for example)
  • mistakes are freaking expensive so better get it right by carefully planning and quality measuring your work
  • much repetition (many doors, many windows) so consolidating tasks means efficiency

so with waterfall one first gather all the requirements for a product, then architect the solution, then dive into a detailed, technical design of each component, code it up, integrate, test test test, repair/fix and release.

with agile, developing software is more like designing a department store:

  • usually there are loose restrictions on the order of the tasks at hand
  • a wide array of features
  • a detailed and strict planning may fail. small incremental steps and proper adjustments moving forward works better (scrum anyone?)
  • centralizing tasks helps to a certain extent

scrum in action:

  • with agile the team goes on sprints (2w minimum for us) when each run gets us one step closer to our goal
  • effectiveness is key: how many features (stories) were coded into the system. less lines of code in general, more code that does what the end user really needs
  • no elaborate MRD/PRD. with agile one maintains a backlog and direct communication. we hold daily meetings, spring planning and we retrospectively learn from our mistakes and success.
  • flat hierarchy across the team and more responsibilities is handed off to the developers. the team self manages using a structured process
  • a team is comprised with complementing skills, so each team can get stuff done on it’s own accord
so agile is more of a philosophy than rules right?
  • every activity is time measured and they are prioritized from the most important to the least. when time runs out we are hopefully better off than before we started as the product work was done priorly to make sure the most important features are on the top of the list (i.e. backlog)
  • with agile the developers are encouraged to write only what is absolutely necessary and most probably we will revisit this code later on for changes and enhancement. this is where a thought through QA process is essential

think of scrum and agile as a framework for getting the job done. depending on the dynamics of your team and size of company agile maybe what you want to implement. i think it works very well for startups and collaborating with small teams when outsourcing projects. at the end of the day agile/waterfall are all ways to increase productivity and allow developers to make the best of their time.

good luck!

why we use mongo DB

from, mongo is a scalable, high performance, open source, schema-free, document oriented database. so the one size fits all philosophy doesn’t work anymore, does it? non relational databases scale horizontally much better. just add another machine and you are good to go, and these days where big data is a big deal – speed, performance, flexibility and scalability are the names of the game. think about it… no schema, no concern with transactions. this is the commoditization of databases. what mongo does is try to perform as a key-value store with the functionality of RDBMS.

speaking of “traditional” database capabilities, mongo can index and has failover/replication support. data is stored as documents in binary JSON format. yes. mongo “gets” JSON out of the box. is your JSON valid? good. you can now import and query it. and no schema means no more ‘alter table’ crap, and the query syntax  is java script based and you can nest your queries as much as you want. moving right along, gridFS can store large binary objects efficiently . images. videos. whatever. just throw it in there.

the documents are just like records. only mongo has them as JSON binary objects. collections are your old school tables if you will. when you query mongo you get a cursor back and not a record per se, and you iterate over the set of result set like a champ. you guessed it. no more loading everything to memory – just want you need. this is a big victory for the performance gods. mongo is wonderful to perform analysis  as it is a data warehouse. dump in your JSON and analyze the hell out of the data.

mongo is not good handling transactions nor maintain the integrity of relationship between data. you can find out more at

how haptic technology may help mobile web

the new world of smart devices has changed the game. for the first time in history last month, mobile use surpassed web. it seems the direction is clear – more robust, engaging and capable devices which are portable, easy to carry and connect us on a personal/social and professional level. every vertical on the planet is thinking of mobile and it can be utilized to achieve corporate goals, save money and enhance communication within the organization.

from the early start it was clear there is one daunting issue with mobile. fragmentation. this issue persists across history, from the inception of virtual machines to the web. ask any front

end web developer of their experience with coding for an array of different browsers and brace yourself for some horror stories that will most definitely make you cherish your choice of profession. yes – the browsers claim the support and implement specific standards, but at the end of the day having a concise experience across the 90% is major pain.

not far behind are mobile devices. a developer builds an app for iOS and now wants to develop it for android and blackberry. good luck. android has more devices out there an screen resolutions than one can count, and while going native is a great idea, one will need to double their effort in order to produce a solid experience across the eco system.

forget you not that the true open standard for mobile has always been the web. steve jobs explained so in the first iphone unavailing back in 2007, and indeed some great technologies have emerged for the mobile web that allow developers to deploy/convert/cross-compile their code so it will either run natively or be compatible across many  devices and operating systems.

while that is a good and interesting market that is just starting to awake, one very quickly experiences the big gaps between mobile web and native applications. most certainly on apple devices. the experience keeps the users wanting more. yes, HTML5’s canvas and CSS3 really offer some great features that do a good job – but it’s not the same and sometimes is not as responsive. let’s face it – a big part of mobile is the experience as it drives engagement which is a big part why mobile surpassed web. just play angry birds on crhome and then launch it from your iphone and you will see what i mean.

i have always been a fan of haptic technologies. in essence haptic provides the user sensory feedback so they can “feel” the surface of the touch screen, which are great, but there is still a missing sensual experience to what one is using. my mom for example does not like touch devices and prefers real buttons. who doesn’t? touch screens take time to get used to and bar none everyone would prefer to work with a physical keyboard for tasks that are longer than 140 characters.

IMHO haptic is a game-changer and one piece of technology that will take user experience to the next level. exposing developer APIs and allowing us to provide our users not only a visual but a sensual experience of the UI elements and interact with our technology on a deeper more intimate level. it may just be what will save the mobile web. touch is stronger than visual in my opinion, especially as displays have more pixels condensed per inch than ever before. how many of you are “blown away” by the new ipad’s retina display? how many of you think it’s “okay”, but certainly not something you would immediately shell out $550 to upgrade your ipad2?

being able to program what our fingers feel as they interact with a touch screen may be what the mobile web horizontal needs so it’s experience delivery is enhanced and gain more traction and acceptance.

auto reference counting with iOS 5.0

iOS 5.0 introduced us to ARC for mobile. this is a major change (advantage) in the way developers  work. what was once a source for memory leaks, which required diligent memory allocation and management, becomes easier and much simpler of a task, allowing developers to focus on the code.

LLVM rocks indeed.

think of it as new ‘best practices’ one should incorporate into their coding habits, while disallowing other practices:

  • no more retain, release, autorelease nor dealloc
  • no more custom retain nor release method implementations
  • do not store obj pointers in C structures (use objects instead)
  • no more direct casting between objects and non objects (e.g. id and void*)
  • you are done with NSAutoreleasePool. use @autoreleasepool keyword to mark the block in curlies.

what ARC should encourage you to do is start thinking about the relationship between objects and object graphs, and not so much in terms of retain/release. there is now a new lifetime qualifiers for objects, which includes zeroing weak references. the value is automatically set to nil when the object it points to is deallocated. we now have qualifiers for vars and new weak and  strong declared property attributes.

apple is providing developers with migration tools which are build into xcode: .

switching to ARC means neglecting support for iOS >5.0.
add custom containers to the mix, much more control over customizing UIKit elements, storyboards, tableView’s new flexibility and much more.

happy coding.