Jack Greenfield has responded to our recent Q&A that touched on the subject of Software Factories. While the Q&A wasn't a technical interview, I'd like to take a more detailed look at this subject and answer Jack's post.
Although I didn't author the original post, I'll take a stab at answering Jack's questions directly:
- Compilers, Class Libaries, Frameworks, Patterns, Best Practices, Databases, Form Builders, and Transforms don't necessarily crush creativity and flexibility. Although, there's no question that using a Form Builder does constrain (aka limit flexibility) the way an interface is developed. Is Word® or VisualStudio® developed with a GUI builder? I doubt it.
- None of the best practices mentioned crush creativity or flexibility. But honestly, I don't see how Defect Tracking (as an example) relates directly to the key concepts in software factories. Software factories didn't invent User Stories, Testing, Refactoring, or Configuration Management, and our post didn't cover those practices.
- None. Frankly, I've never built an application with a software factory nor have I spoken with a company or developer that's used it. As soon as I have the opportunity to get that proof, I'll be sure to blog it.
There is no question that the original post took issue with the term "software factory" in areas more than Microsoft's exact definition of a "software factory." It's turns out Microsoft does't mean "factory" in the literal sense. Don't they love re-defining English? I also take issue with Microsoft's concept of a software factory for slightly different reasons.
Developers that are part of a software factory crush themselves over time.
I love patterns. However, I wouldn't love to use a tool that only allows me to create applications in terms of pre-described patterns. While this is an extreme example, it's quite near to the reality of software factories where developers interact with a visual modeling environment and a domain-specific language (DSL) engineered to leverage a set of pre-built patterns and libraries.
Adapt or Die
Earlier in my career, I had to opportunity to build applications for a bank using a 4GL tools -- specifically Informix 4GL (anyone remember that). The environment was awesome for building form-based applications against Informix databases. However, over time the bank starting migrating dumb terminals to PC's and the demands for client-server applications grew. The expert 4GL developers struggled to make the transition. Their experience and skillset were constrained and limited by the environment they were working within and begun to realize that the knowledge didn't readily adapt to the burgeoning world of client-server. Luckily, 4GL was just one of the technologies I used, so I was able to adapt. Why does this matter? Some researchers see 4GLs simply as a subset of DSLs.
Interestingly, look at the SAP development community. For years, they had special programming languages and environments. Now, they are moving their entire community to tools based on J2EE and Eclipse. Sure, they have a set of customized frameworks and editors for SAP-specific development, but developers have the full richness of a broader platform for integration and customization. This is good news for a SAP developer whose skillsets are now more applicable to other domains.
Cooking with software factories
In a recent piece, Jack coined a cooking analogy describing schemas as the list of ingredients and templates as the bag of groceries, which are all cooked up in the VSTS kitchen. That won't help developers using non-Microsoft IDEs, scripting languages and frameworks, who target multiple delivery platforms. Developers using SFs will struggle to meet the needs of projects in mixed IT shops deploying to Windows and non-Windows PCs and devices. But...Microsoft could care less about that...
To us, it seems that developing with SF is a lot like working as a line cook at a chain restaurant such as TGI Fridays. Many of the ingredients for the entrees are pre-prepared, frozen and available for cooking and assembly. The recipes are mandated from corporate and every TGI Fridays has food that tastes appreciably the same. I suppose there is a certain elegance to the consistency.
Now compare that with a chef like Charlie Trotter. He has a set menu at his restaurants, and many of the building blocks (sauces, stock, etc) are made in advance by him or a sous chef. However, he has the skills to adapt the menu based on need. Maybe he's serving a large group with special dietary needs - he can construct a menu to meet their needs. Maybe a certain seasonable vegetable is particularly fresh and could be integrated in a few dishes. He has the raw skills and ability to adapt based on changing need. He is Agile.
Versatilists
Thomas Friedman in The World is Flat listed 4 roles that are most likely to maintain their jobs in a flat world. The role most applicable and attainable to software developers is a versatilist (unless of course you've attained developer rock-star status like DHH or Erich Gamma). A versatilist is someone who can be a specialist yet also adapt and evolve as needed. In this interview Friedman advocates CIO's focusing on making all their people versatilists.
So in an age where being versatile is more important, are software factories really addressing the needs of developers?
Great post from Kathy Sierra about challenging assumptions. According to Kathy, the thing about assumptions is they become so ingrained that people don't even know they are dealing with assumptions - assumptions have become fact.
Assumptions are a real problem when it comes to building software, because they can lead to things going wrong and as a result both money and time get wasted. Here's a brief list of some common assumptions that can be held by those on the business and IT side of the house when it comes to software projects:
- Everyone shares the same goals
- That IT has the necessary skills and resources to complete the task competently
- The engineering team has fully and clearly understood what it is they've been asked to deliver
- That business has been made aware of potential problems and limitations with the project
Read More
With software developers descending on Las Vegas (Mix06) and Santa Clara (EclipseCon), it�s high time we updated you about events at 6th Sense Analytics that should appeal to both communities. 6th Sense Analytics is close to debuting a browser-based service that helps software developers focus on doing what they care most about (developing) and also allows the business to get on with what it cares most about most (business).
Read More
"In software development optimism is a disease, feedback is the cure." ~Kent Beck, Agitar Fellow
6th Sense's simple goal is to improve software development by providing feedback. Welcome to the newly launched 6th Sense Analytics website. You'll notice that this website is a tad different. We opted to make our home page a weblog to provide you with fresh information as we evolve our company and products. Our goal with this inaugural post is to introduce 6th Sense and cover some basic FAQ stuff. If we don't address your question, feel free to email us at info@6thsenseanalytics.com. Your question may even be the topic of a new post here.
Read More
I had the opportunity to attend OSCON in beautiful Portland, OR this week and thoroughly enjoyed it. It certainly lived up to its billing as having the veritable who's who of the Open-Source community.
No other conference will you find so many representatives of the 'P' languages -- PHP, Python, and Perl. I've sadly ignored the 'P' languages for the most part. Sure, I've periodically used PHP to customize our web infrastructure (blog, forge, etc). I used Perl a long time ago when I work on large UNIX-based software systems, but I wouldn't consider myself a Perl hacker -- although the camel book from O'Reilly is one of my all-time favorites.
These languages are unique in that they inspire a passion for language that is very cool. When I'm at JavaONE, developers don't corner me and say, "I love Java," or "You've got to use Java for your application development -- you'll improve your productivity" or "It's impossible to write ugly Java code."
Java doesn't inspire passion. I've been using it since 1996, version 1.0. Every major application since 1996 that I developed, sold, and lived on was written in Java. Yet, I'm not passionate about it. I was in 1996, but I'm definitely not passionate about it now. Python's been around for almost the same time as Java, Perl's been around for much longer and developers are "giddy" about it.
This is not just a new thing. C# is very new and is quite nice. It was developed by a very cool guy, Anders Hjelsberg (also the creator of Delphi which has a very passionate following), and it is my language of choice for writing .NET applications. However, C# doesn't seem to inspire passion -- even among the .NET community.
Java, C#, and others (C, C++) don't inspire passion because they are the status-quo -- the languages used in the development of most business applications. They achieved this status through the support of major vendors. Sun and IBM hitched their wagon to Java, developed middleware and tools in Java to make it easy for big corporations to adopt. Same for C# and Microsoft. While there are pockets of Perl and Python in big companies, they are not the predominant force.
Look at PHP...it was extremely cool a few years ago. All the tracks at conferences were about PHP and the community grew. A year ago, IBM pledged significant support for PHP in conjunction with Zend, and now the excitement is starting to quell. No one cornered me at OSCON this week to tell me why I should use PHP.
Here's a graph illustrating the adoption vs. cool factor of languages. The challenge for the cool languages is how they increase their adoption without losing the "coolness". The typical pattern is illustrated on the chart.
Prove it
I'm going to propose an alternative way for these languages to grow in adoption: prove it with data. Focus the passion on discovering ways to quantitatively prove that your language is better. I'll let the creative folks in the community determine which metrics are the appropriate ones to use. Proving that a language is superior can be all that's needed to make the business case to increase adoption and usage. Management at big companies (people that pay for things) need proof to jump to technologies because there is risk with it. IBM, Microsoft, and Sun mitigate that risk for them. However, your data can help make the case with or without the big vendors. And because the business case is made by the community -- it maintains the mystique, hype, and excitement around the technology.
I'll end on a challenge for you passionate Python, Ruby, and other hackers (sure Erlang, Haskell, and Lisp aren't excluded): Prove with our data that your language is superior. We'll gladly try out the first proven language on the next project we undertake and will publicly report on our progress. If there's a metric that we don't have that's essential for your proof, send us an email, and we'll see what we can do to add it.
Our Desktop solves a complex problem. It integrates with multiple versions of 6 development tools, running on 5 operating systems (Windows, RedHat Linux, Suse Linux, CentOS, and Mac OS X), and is accessible via 4 web browsers ( IE 5.5+, Firefox 1.5+, Safari, and Opera 9 ). Combine this with the fact that it operates through firewalls/proxy servers makes the problem even more challenging.
Sounds fun, doesn't it?
This release is a significant milestone for our young company and is the culmination of a large re-design based on our collective customer experiences. When we sat down to plan our development of the new Desktop, our data was a huge factor in our decision-making. Despite the 6 calendar months invested in the development of the first version of the Desktop (including minor bug-fixes, etc), we had only 120 cumulative active development hours. Our team averages about 100 active hours each week. Given the depth and significance of our desired changes and the relatively small investment in the Desktop, the decision to start from scratch and rewrite the Desktop was pretty easy (as easy as these decisions can be).
5 weeks and 450 active hours later (yeah we added some stuff), 6th Desktop 2.0 is ready.
Key Highlights
- Brand new UI for managing sensors
- All new sensor infrastructure for simplifying sensor behaviour (updated each sensor)
- Support for multiple installations of 1 sensor ( great for your 3 versions of Eclipse )
- Support for multiple users on 1 install ( great for shared machines )
- Migrated to ports 80 and 443 for all communication
- Numerous enhancements to sensors
- VIM sensor reimplemented and now supports installation in Cygwin.
- 20+ bug fixes
If you have any feedback or suggestions don't hesitate to write to support@6thsenseanalytics.com
By all accounts, BarCampRDU was a huge success, and we couldn't agree more.
First, thanks to the organizers (Fred Stutzman and company) for the outstanding job. Second, thanks to all the sponsors (including Red Hat for the space). We are proud to be part of the group that helped make the event possible.
We gave several presentations including product demonstrations, "Ajaxifying web development with Dojo"; and "The shape of things to come in Scalable Vector Graphics". All sessions were well-attended and were a lot of fun to lead.
Read More
When Sun Microsystems' co-founder Bill Joy said at JavaOne 2003 "innovation happens elsewhere" he summed up the innovators' dilemma in one handy sound bite. That dilemma: how to harness the power of smart people, not necessarily on your team.
That question returned with the publication of a book by two Sun engineers the title of which borrows Bill's words. "Innovation happens elsewhere" is an attempt by the duo to explain what steps companies can take to harness the creative works of others.
While the book tackles how to engage with the community on open source, the question of how to harness creativity is a burning one for everyone with a stake in software development.
People - in our particular case, developers - are an organizations' biggest asset in building software, and often you will find the people most important to this process are those furthest down the management chain, and closest to the shop floor.
These people demand the kind of culture that enables their talent to flourish. One of the book's authors, Ron Goldman, this month highlighted on Sun's developer network (here) some steps employers can take to establish such a culture. These range from opening up the development process so that decisions are taken openly and publicly, to establishing an atmosphere of trust and collaboration, and fostering a set of passionately shared goals.
Fundamental to all of this, though, is the need for organizations to recognize that for software projects to grow and flourish (and hit deadlines) they require different types of skills. People contribute in different ways - in design, testing, coding and writing.
That may seem obvious, but the reality of the workplace is different. Pressures of deadlines or a lack of suitably qualified individuals means projects often suffer from under staffing or a lack of people with the right type of skills. This means developers' workloads increase, often in areas where they many not be specialized, leading to loss of productivity, de-motivation, bugs and delays. This is especially true when companies outsource parts of their application development process, and those members of their application team who remain must either hold the hands of the outsourcing supplier or correct their mistakes.
Good software gets built by staff who have the resources that let them flourish and who are surrounded by a healthy support system. That means employers must build a software-based infrastructure with companies like 6th Sense, which helps identify potential bottlenecks, provide adequate training and tools, and spread workloads across the team so individuals don't become overworked.
The right infrastructure will help build the culture of trust and collaboration, and help ensure goals are shared passionately and that innovation is harnessed.
You will never resolve the fact there's always going to be more smart people outside your team, but you can take big steps towards bringing them onboard and ramping up the creativity of your team using the right infrastructure.
Tekrati's latest opinion piece has summarized the pain that sub-par market research departments cause their businesses: they "confuse managers, cloud decisions, hamper forceful execution and consume valuable resources."
Tekrati is talking about the practice of bringing in external IT analysts to advise on proposed new product and services. Tekrati, though, could easily be referring to the impact poor research and insight has on application development and on the growing practice of outsourcing large portions of the application lifecycle management chain.
Read More
There's something really weird about being a member of the IT industry and going to a conference that feels the need to discuss the importance of "innovation." I've always believed a fundamental acceptance in the concept of innovation was table stakes for this game.
Apparently not, though, if the level of discussion at last week's start-up and VC dominated Supernova 2006 conference in San Francisco, California, was anything to go by. No wonder the US is worried about China and India.
It's not just in new business and technological break throughs, though, that people should be concerned. Innovation is a relative concept. Yes, the eggheads at MIT are finding bold new ways to cool super-heated chips, but what does that matter to organizations trying to solve business problems using software or to solve their software delivery problems using improved processes?
To these people, innovation is a relatively small but equally vital affair: it comes in the form of realizing an idea in code or finally solving the bug that kept causing a new application to fall over. Often, though, this level of innovation cannot flourish because there is poor insight into software projects. This means innovators are not receiving the resources they need and problems cannot be identified early, so software projects run late and over budget.
That's where 6th Sense Analytics comes in. We believe a vital component of successfully delivering software is insight. That means, having a view into how your application development people are working so you can know where they need resourcing in order to deliver the day-to-day breakthroughs that allow your company to successfully deliver its software projects on time and on budget.
We provide the data that gives you the information you need to act pro-actively. Our data is unquestionably accurate: unlike some tools, the data you will base your important decisions on is pulled straight from the developers' desktop, not some after-the-fact reporting tool, meaning you know exactly what's has happened in projects, not what someone imagines has happened. Plus, we deliver the data from all the open- and closed-source assets in your application development portfolio, not just one vendors' tools or just a single platform.
Data is important, however at 6th Sense Analytics we give you more. We give you the information that empowers your people to innovate and that helps drive your success.
