By definition managing “big” development projects usually translates into “big” teams with “big” capital investments. Contemporary analysis of traditional IT projects indicates these big projects also have a high degree of failure risk. Many leaders believe having extensive reporting and oversight will ensure timely completion and reduce risk. However in meetings and reviews, confidence in outcomes is always debated and we tend to manage to worst case. I think it’s easy to look at the continuous software delivery of large social media companies and think the same can be achieved at a large enterprise. One big difference relies on the mission criticality of enterprise applications, especially in healthcare. Sometimes software development suffers from Parkinson’s Law, which is the adage that “work expands so as to fill the time available for its completion.” It’s best to attack Big with Small as in Small Teams. Project resourcing is non-linear - by doubling resources, you don’t double output. Large teams have inherent management overhead just to keep them going and it’s better to parse out the work. You have to delegate authority to your program leads. We have a concept of “staying on the reservation.” If you let your leaders know their decision-making levels, then they can confidently make decisions without wandering off the reservation. The voice of the customer has become a new buzzword in agile development recently. Augmenting development with customer feedback in real time using best practices from market research will result in better products from the get go. Design is so much more than just gathering requirements - design is everything! Utilizing DevOps and related technology tools will speed up delivery and support of the complete solution and you can move from a minimum viable product to a minimum marketable product more quickly. As teams learn, work and grow together, mutual trust will develop and competency will increase. Only through trust will team members feel secure enough in their role to be transparent with their abilities and ask for help early on before their work goes off track. A smaller team at a smaller table is a better place to work out those types of development challenges.
A technology area that drew increased interest and investor capital last year was 3D printing. While the underlying mechanics have been around for over 30 years, it has recently become a hot topic for both consumers and business leaders. It combines many tech domains such a software, materials science, manufacturing, optics and both mechanical and electrical engineering. It changes the way we think about building things because rather than using “subtractive” methods, like cutting blocks of material or “formative” methods using molds, it uses “additive” techniques. Items are built layer by layer from digital design files using many different printing technologies. It has the power to create a multitude of niche, personalized products as well as enabling a transformation in industrial manufacturing on a global scale. Promising applications for healthcare such as skeletal implants, prosthetics, replacement windpipes, facial implants and dentistry are already emerging. Companies like Align Technologies for straighter smiles and Organovo for living tissues are leading the way. Scientists are growing human cells from biopsies or stem cells then using 3D printers to arrange them in ways the human body does. VentureBeat reports that there were more than 50 new startups raising capital in 2014 and over 40+ crowdfunding projects. There was even a 3D printed car by Local Motors at the Detroit Auto Show. The underlying technologies such as Selective Laser Sintering (SLS), Fused Deposition Model (FDM Stratasys) and Stereolithography (SLA) are fascinating and will continue to attract research and development talent. Some analysts characterize 3D printing in the Internet of Things category and include it in many “Top 10” technologies for 2015. It has gained a large hobbyist following and has sprung up a whole cottage industry. You can even make a 3D figurine of yourself using Doob by jumping into a 3D photo booth! (Image: Ben Sandler)
There has been quite a bit of buzz recently over a report by RedMonk showing the rapid developer adoption of Apple Swift. The new programming language was introduced in June of 2014 and is Apple’s successor to Objective-C. The report draws correlation between discussions on Stack Overflow along with code usage statistics from Github. The authors caution to take the numerical rankings with a grain of salt. Many comments correctly point out that it simply reflects how interested developers are, but not necessarily any demand from employers seeking those skills. Objective-C is a powerful language but suffers from many of the low-level technical syntaxes that challenge C and C++ developers. Swift is intended to be a replacement to Objective-C while maintaining high compatibility and integration. Swift cleverly combines object-oriented & functional programming with dynamic language features along with runtime managed code support like Microsoft .Net. I used to always say, “Happiness is managed code.” The interactive coding and debugging in Swift Playgrounds integrated with Apple’s Xcode IDE adds a bit of RAD (rapid application development) to the developer experience. Most mobile application firms are doing early prototypes and training for Swift with their iOS developers and the language will continue to mature. Since mobile app projects have relatively shorter development cycles than enterprise applications, the adoption should continue at an accelerated pace. Many Ruby developers will also find that Swift is easer to use and understand than Objective-C. Existing Apple shops with a good inventory of Objective-C libraries can use those assets with Swift since the new language is cross-compatible. Within three years, I expect it to replace not only native iOS apps but also applications for Mac OS too.
Crowdtesting is another market disruption that stems from Crowdsourcing and is making its way into the software development world. Crowdtesting is a new way to verify and validate application testing on a variety of dimensions including functional, usability, performance and mobile capabilities. The testing approach is most popular with organizations developing customer-facing applications that are mobile or web-based. One benefit of crowdtesting in the agile process is that it provides early feedback from a broad testing population pool not tied to the organization or the development team. A couple of firms amassing a large population of testers are uTest with 100,000 and Mob4hire with 60,000 registered testers. The crowdtesting companies provide tools, training and a community of interest for their virtual workers. There are two primary delivery options, termed “communities,” and come as “vetted” and “unvetted.” The application owner would select a vetted community if functional, performance, security or localization testing were needed. An unvetted community would be selected for early exploratory or usability testing. Application owners are responsible for understanding and verifying the testing methodologies used so that bug identification controls are in place to prevent defect leakage or reinjection. Any crowdtesting initiative must pass company compliance and regulatory controls since by its very nature, can cause security risks. Payments for services are typically based upon the number of defects found; a defined pre-allocated budget based on contest or outcomes, or per device and platform for mobile apps. By structuring the contract based on quantity found or time-bounding the process, you avoid protracted testing time that could delay implementation. Crowdtesting is becoming commercially interesting to global service providers with application service resources on their bench. If service providers have steady business that absorbs 75% utilization of their testing staff, they can deploy the remaining 25% to crowdtesting. This improves their operating profit as it keeps their overall resource utilization rates very high.
High-quality DevOps practices produce a seamless flow of continuous development, deployment and maintenance of large-scale web applications. Today’s business environment demands accelerated releases of functionality from inception to production code. The notion of allowing developers to push code directly into production sets off alarms for most traditional IT leaders. Many experienced development managers recall stories of mistakes made in production environments, some resulting in significant business disruption. However, leading large-scale consumer sites such as Google, Facebook, Netflix and Amazon have adopted these practices and push small code releases every day at an enormous rate. Agile DevOps has its roots in Lean and Kanban. In lean manufacturing, cycle time is defined as the time from when a work product is started to when the finished work product is delivered. For software, this corresponds to the time between when a user story is created to when the story is real code in production. For many high volume sites, the preferred batch size for a release is a single user story. Each story is put into production as soon as it’s complete. Due to massively dense server farms, there is no way to do this manually and automation tools must be used. We see engineering style alignment with these tools such as Puppet or Chef. If you’re coming from the dev side of DevOps, then the procedural nature of Chef using Ruby is natural. Puppet appeals to Ops pros since it is more mature, data driven and geared toward sysadmins. DevOps seeks to bring these styles together. The freedom of allowing developers to push code into production also comes with the responsibility to ensure stability of their code after deployment. A cultural shift from Project-based IT to Product-based IT is necessary to make DevOps successful. If not, then you have speedy agile development sprints constrained within quarterly or monthly waterfall release cycles. Bottlenecks upstream and downstream outside of normal scope are addressed more readily in a product-based construct. The attitude changes from “it’s not my job” to “it’s my workflow” - and a strong sense of ownership accompanies this new attitude. With increased velocity & cycle time, we can use metrics of mean time between failure and mean time to restore service rather than the number of lines of code produced or number of defects resolved.