What Happened to Software Engineering?

July 27, 2011 § Leave a comment

What Happened to Software Engineering?

(- By Phil Japikse)

Over the past few years there has been an evolutionary shift in the world of software development.  Not very long ago, the dominant Software Development Life Cycle (SDLC) methodology was the Waterfall Method with very specific phases that separated the construction phase from phases like design and test. The software development industry, still very new, was striving to find a repeatable, predictable process for developing software.

The best model for this seemed to be the physical sciences, like civil engineering and architecture. Artifacts like detailed requirements, design documents, and technical specifications were written and signed off on long before a single line of code was developed, similar to the process used in construction of physical structures like bridges, buildings, roads, and dams.

To further align with the physical sciences, job titles like “Software Engineer” and “Solutions Architect” were adopted.

This style of project management has been very successful in construction.  Yet a significant number of software projects were failing outright, and many more went significantly over budget and/or missed deadlines.  This was due to several factors, but probably the most significant have been both the speed of change in software and hardware and the speed of change in business needs.  These changes in the software industry would be similar to that of having brand new vehicles requiring a complete redesign of the roads they drive on about every 18 months.

When civil engineers are asked to build a bridge across a river to join two roads together, the engineers building the roads have fairly exact coordinates defining where the roads will come together at the river, and vehicles haven’t changed significantly over the years.  The bridge engineers merely have to join the two roads together using tried and true construction techniques that have been employed thousands of times before.

In software systems, it’s not unusual for technology or changing business needs to significantly change the requirements during construction (after all of the requirements and design documents have been completed).  To put it in the bridge building analogy, it is like having one of the roads moved six miles downstream after the bridge foundation was already in place.

To counter these issues Software Engineers developed many new techniques and practices designed to refine the construction phase through improvements in software quality, code reuse, and productivity.  Some of these new practices include defining (and enforcing) code standards and naming conventions, encouraging the use of proven software design patterns, using tools like unit test frameworks and techniques like Test Driven Development (TDD), followed by Behavior Driven Development (BDD), continuous integration, and  pair programming. These techniques were very effective in reducing defects and improving the construction phase, becoming commonly referred to as Software Engineering Best Practices.

While practices for refining the construction phase were evolving, there was also a lot of study into refining the additional phases of software development such as requirements definition, systems design, quality assurance, and testing.  These included Scrum, Extreme Programming and Kanban (the adaptation of Lean Manufacturing) to name just a few.

This reflection resulted in the development of what are referred to now as the Agile Methodologies.  In fact, a significant number of the practices to improve software construction like TDD and Continuous Integration were developed alongside the process improvements that would later come to be called Agile.

Today, agile methodologies are rapidly moving from the fringes to the mainstream, penetrating even the largest enterprise software development teams.  The agile revolution has brought about a lot of change, and exposed many of the problems that developers faced in using the old waterfall approach.

Conferences, Open Spaces, and classes are filled with discussions on how to be better at agile, focusing on topics like how to best manage the backlogs, run retrospectives, plan sprints, and other process oriented topics — all extremely important items that need to be well understood and implemented correctly as teams move to agile adoption.

What tends to be left behind in all of the agile excitement is the Engineering Practices that were developed to deliver higher quality software.  Most of the agile methodologies focus mainly on the process management topics and don’t discuss construction techniques in their teachings (the main exception is Kent Beck and Extreme Programming).  I believe this due to the agile methodologies assuming you are already doing the technical practices!

Unfortunately, in my career as a consultant and an agile coach, I have seen all too often that those engineering practices are being left behind. This could be due to one or more of the common mistaken assumptions surrounding agile, or the lack of emphasis from some of the major certification programs in agile.  Or it might just be that the term Software Engineering has developed a stigma from the waterfall days.

We grow as an industry when we learn from those that came before us.  Even process reinvention takes into account what is already known, incorporating what works and eliminating what doesn’t.  By removing all of those Software Engineering Practices like Test/Behavior Driven Development, Continuous Integration, and Pair Programming we are forgetting what counts at the end of the day: developing high quality software.

All of the other processes that come with the agile methodologies are important as well in achieving our goal, but don’t throw the baby out with the bathwater.  I go by many titles these days, including Speaker, Agile Coach, and Writer.  At the heart of it all, I am a Software Engineer.  And proud of it.

Microsoft Office on Android: The Best 2011 Response to the iPad

July 27, 2011 § 2 Comments

Microsoft Office on Android: The Best 2011 Response to the iPad

Google and Microsoft have a problem — and to sum it up, that problem is Apple.

Google has tablets but they aren’t selling well against the far more complete iPad offering. Microsoft won’t have an iPad competitor until well into 2012. Google is having an issue with relevancy on tablets and Microsoft loses not only a Windows footprint but an Office footprint with every iPad sold.

What if the two partnered? Ironically it isn’t as hard as it sounds. You could actually see how this could work today.

So let’s explore Microsoft Office on Android this week.

Microsoft’s iOS Risk

While most of us are focused on the iOS vs. Windows fight, that really isn’t where Microsoft’s pain actually totally resides.

The iPad and iPhone are a rethinking of the Mac in preparation for a world without Microsoft. You see, the iPad doesn’t just replace Windows it replaces three Microsoft pillar products: Windows, Office, and IE. And it challenges affinity for a Microsoft back-end, too, showcased by how aggressively companies like IBM and BMC embrace the iPad and iPhone for their corporate management application consoles.

What Apple is attempting to do is replace Microsoft completely. They already have around 20M iPads out in the market that are very similar to PCs but don’t run a scrap of Microsoft code, nor do most connect to Microsoft services. This represents a far bigger threat to Microsoft’s existing revenue streams than does Android, which has largely failed on tablets; the Chrome OS, which isn’t selling; and Search, which is chewing up massive amounts of Microsoft cash.

Google/Microsoft Office Problems

On the other hand Google just doesn’t seem to get desktop applications. All of the Google tablets I’ve tested are plagued with poor productivity tools and bad Exchange integration. This last showcases primarily as an inability to sync calendars.

Apple, back in the early days, originally went to Microsoft to solve this problem with Word and Office for the Mac. For the Android tablet to be successful Google needs similar help. Office has been its own product for years and has versions that run on both the Mac and Windows. As the iOS displaces the MacOS the Mac version of Office is being locked out as well. And Microsoft currently lacks a competing product to the iPad in market and won’t get one until 2012.

In short, because Office is the productivity standard it would, on top of Android, substantially improve that platform and make it vastly more competitive to the iPad/iWork offering from Apple. And given Microsoft has separated Office from Windows Office on a successful tablet, this move would allow Office to compete with iWork more effectively than it can now. The result being a stronger hedge against erosion due to Mac displacements by the iOS.

Now if you think this can’t be done, try Office Live or Office 365 on Android and you’ll likely get the best Word processor experience available for that platform. And Outlook Web access provides a calendar that works if you don’t go the Office 365 route.

Office 365 is a new online suite for Small Business with everything (SharePoint, Exchange etc.) included. All they’d have to do is position it on Android. Granted it would be better as an App — you could work online but it could be, and in many cases is, an answer for the shortcomings in the Chrome OS and Android tablets.

Interesting enough, Office Live won’t work on the native Android browser (you can view but not edit). But it will work on Opera for Android so you can load it that way and the experience isn’t bad. In fact compared to the alternative, it is damned good.

In short, and clearly unintentionally, Office Live/365 already makes Android Tablets better. On an Asus Transformer Android Tablet, my personal favorite, running Office is the best Microsoft alternative to the iPad in market. I actually like this combination better than an iPad.

Wrapping Up: Putting it All Together

Microsoft needs a way to weaken Apple enough so that the Tablet market doesn’t become an iPad market before Microsoft can ship Windows 8. Google needs a vastly better productivity solution for Tablets than they currently have.

If Office were still tied to Windows as a primary enabler this wouldn’t work but the two offerings have largely been separate since Windows XP. This suggests that Office on Android could actually work, and if you have an Android Tablet, load the Opera browser (which isn’t a bad browser for these tablets anyway) and give it a shot.

You may find it makes these things far more useful than they otherwise would be. I find it ironic that the best alternative to an iPad this year may be an Android Honeycomb Tablet running Microsoft Office Live on Opera. You talk about your strange bedfellows.

Apple refreshes MacBook Air with Sandy Bridge, Thunderbolt, and backlit keyboards

July 22, 2011 § Leave a comment

Apple refreshes MacBook Air with Sandy Bridge, Thunderbolt, and backlit keyboards

They say Apple updates its products like clockwork, releasing something new at the same time in the same place every year. Not so with MacBook Airs anyway. The outfit’s gone and freshened up its 13-inch and 11-inch ultraportables — the second such update in nine months. Although the industrial design hasn’t changed much since the last generation, both models step up to Sandy Bridge Core i5 and i7 processors, Thunderbolt ports, backlit keyboards, and, of course, OS X Lion.

The 11.6-inch flavor starts at $999 with 64GB of solid-state storage, 2GB of memory and a 1.6GHz Core i5 processor. The higher-end of the two configurations costs $1,199, with the extra two hundred dollars doubling your RAM and storage. The 13-inch Air, meanwhile, starts at $1,299, with a 128GB SSD, 4GB of RAM, and a 1.7GHz Core i5 CPU. Step up to the $1,599 model and you’ll get a 256GB SSD instead. Regardless, you’re looking at Intel HD 3000 graphics across the board, along with FaceTime webcams, two USB ports (plus an SD slot on the 13-inch version), 802.11n WiFi, and Bluetooth 4.0. The two differ when it comes to resolution and battery life: the 11-incher has a 1366 x 768 panel and is rated for up to five hours of battery life, whereas the 13-inch model has a 1440 x 900 screen and promises up to seven hours of juice. As for that 1.8GHz Core i7 CPU, it’ll set you back an extra $100 on the 13-inch version, and $150 for the 11-inch version. Whichever size you choose, it’s only an option for the higher-end configuration. Hit the source link to peep the specs and buy one, if you’re so inclined.

Show full PR text


Top 7 Things to Know About Web Service Security for Windows Phone

July 11, 2011 § Leave a comment

Top 7 Things to Know About Web Service Security for Windows Phone

(source : codeguru.com)


As an increasing number of mobile applications trend toward web services for making the applications appear “live”, it is important that the requests that the application makes consider adequate security procedures. Let’s understand some of the things that a Windows Phone developer should consider when designing a Windows Phone application.

Only Basic Authentication is Supported

The Windows Phone 7 platform is based on Silverlight 3. However, the Silverlight platform for Windows Phone 7 only supports basic authentication. This means that Silverlight 4 networking features such as NTLM authentication,UDP multicast client, and WCF RIA services are not supported for Windows Phone 7.

WCF Data Services Are Not Supported

Previously called ADO.NET data services, Windows Phone 7 operating system does not support WCF data services.

JSON Serialization Support

Windows Phone 7 platform does not support complete JSON serialization. However, partial serialization support is available through the DataContractJsonSerializer class.

Sockets and Custom Bindings

Sockets and custom bindings are not supported in Windows Phone 7 operating system.

Basic Authentication and HTTPS

Since Windows Phone 7 operating system only supports basic authentication, it makes the scenario of HTTPS calls more interesting. To exercise the HTTPS scenario, you need to have an HTTP connection over a Secure Sockets Layer (SSL) or Transport Later Security (TLS)connection.

You achieve this by specifying a URL starting with https://, and Windows Phone platform takes care of the underlying wiring. When you make a call to an https://” endpoint, Windows Phone checks the certificate returned by the web service and verifies that the certificate is from a trusted authority. Once this is verified, further communication takes place in an encrypted environment.

Mutual Authentication Not Supported

Windows Phone lets you install trusted certificates on the device. However the Windows Phone platform does not expose the certificate values to applications running on the device. This limits the application from implementing mutual authentication scenarios.

Promoting For Credentials

Safe programming practices dictate that it is most secure to prompt the user for credentials when the scenario demands one. However, applications today in the name of usability allow storing for credentials on the device itself so that applications can use them without prompting a user. When storing credentials on a phone, please be sure to apply appropriate encryption.


In this article, we learned a few important things every application developer should know about security using web services in their Windows Phone application.

Where Am I?

You are currently viewing the archives for July, 2011 at Naik Vinay.