Like nearly everything in this imperfect world, software projects always fail for the combined effect of a number of reasons. But if I have to indicate just one reason behind failures–if not the primary reason, the root of all software evil–I’d point at requirements.
The point is not requirements per se; users exist and pay just to express what they think they want. And users–if left alone in the process–tend to accumulate tons of bulleted points regardless of order, relevance, common sense, applicability. It’s not the user to serve an ordered list of requirements; it’s you–the architect.
The good architect critically acknowledges requirements and challenges users. Sometimes you may find posts emphasizing the importance of saying “No” to users. Saying “No” is sign of courage but if “no” is said regardless it may sound outrageous.
How would you understand when it’s the right time to say “no”?
You must grab first the big picture of the system and the underlying domain. If you don’t get it, you hardly can question requirements. Or, if you do it, and users reply, then you’re stuck. So systems are built with an incoherent set of features. Worse yet, systems are built without a clear strategy and message and the UX is the first sign of limited effectiveness.
A decade ago, when DDD was first introduced, Eric Evans brought up the valuable theme of the ubiquitous language. Ubiquitous language was a way to push architects, users and stakeholders to use a common and business-specific language when talking requirements. By sharing a common vocabulary, all parties could point the same thing in the same direction reducing misunderstandings.
To me, today, ubiquitous language sounds more like a generic mild directive such as in the picture above the “easy to use” requirements. We need more concrete guidance in order to build a working set of requirements to turn into UX and logic. I’m not sure we find anything like this in DDD and its derivatives. Also because this is NOT the realm of DDD and its derivatives.
I dare say that the first step in a new, possibly right, direction is approving a sort of Copernican revolution in software architecture: why not starting your design from the presentation layer? Well done domain and business layers are key to have, of course, but UX and system design start from the presentation. If you start from there, though, you are forced to understand requirements correctly. And from there, you’re very well positioned for next developments.
Ottobre 2010, il mondo aspetta Windows Phone e Francesco passa il suo tempo a cercare news su Internet. Io sono a Vienna per un corso. All’improvviso arriva una telefonata a casa-è il Funky Professor che cerca di capire se Francesco, che ha risposto al suo appello, ha davvero 12 anni. Il risultato è qua e il resto della storia è ben riassunto qua nel blog del Funky Professor: http://funkyprofessor.blogspot.it/2010/11/il-funkyprofessor-e-gli-indigeni_17.html.
E ancora, come non ricordare l’invito a Francesco a Milano in Microsoft per la consegna del prezioso Windows Phone e la risposta “Mi dispiace ma quei giorni sono a Las Vegas per DevConnections.” E poi quasi a mitigare “sa signor Zamperini … accompagno papà“.
E poi a Codemotion 2012 quando si incontrano quasi per caso durante una sessione e il Funky Professor che letteralmente trascina Francesco fuori dalla sala per coccolarselo. E le cose che ci ha raccontato degli indigeni digitali e del più bell’indigeno di tutti: la piccola Blanca.
No vabbé io oggi ho voglia di spaccare il mondo. Fanculo il mondo, fanculo la vita. Ma che scherzo del cavolo è questo? Come può sparire dal mondo reale una persona così? Nè è di conforto il fatto che il suo lavoro non sparirà e che i semi digitali che ha sparso frutteranno né più né meno di quelli reali.
Sì, io sto piangendo. Come non avrei pensato di poter fare. Ciao Marco un accidenti. Non dovevi andartene e basta. Sì, l’infarto … sì, la morte … ma che razza di scusa è?
The fiercest enemy of software is mud. Ouch and what’s mud? It’s a kind of sticky matter and results from the mixing of earth and water. The effect of mud is making every step and most actions hard to accomplish. It makes you slip; it, in a way, stops from progressing.
The association between mud and software is an old one and dates back to 1999, when Brian Foote and Joseph Yoder published this paper. Mud stops software from progressing towards its natural end–a successful application possibly built on time and budget. What’s the mud effect on software? What are the earth and water that mixed together stop progress of software? In the paper, Foote & Yoder call a big ball of mud (BBM) the following:
A system that’s largely unstructured, padded with hidden dependencies between parts, with a lot of data and code duplication and an unclear identification of layers and concerns—a spaghetti code jungle.
A BBM is then a software near its unnatural end, starving, about to die. A few key facts can be listed about BBMs:
- BBM doesn’t get formed overnight and grows over time;
- BBM isn’t that big in the beginning and sometimes it doesn’t get noted timely;
- No individual developer is so skilled and powerful to create a BBM all by himself: it’s always teamwork;
- Communication issues between development and business which creates a mismatch between expressed requirements and actual features coded.
- Precision of estimates—doesn’t exist! Uncertainty reigns and trust between parties is required to make progress.
- Requirements churn. An high frequency of change of requirements make the system change context eventually evolving into something that may have required a different architecture.
- Role of management. That crazy little thing called “being a team player …” may hide a lot of painful points.
As emphatic as it may sound, software projects rarely live up to expectations. In the industry, software has often been assimilated to civil engineering; but, if civil engineers are set out to build a bridge, then a bridge gets built. Chances of success are well over 90% and, more, the bridge almost always functions correctly and is built fairly close to budget. (Notable exception is Italy, but that’s not going to be a valid test case :))
What if we talk about software engineers?
If a team of developers is set out to develop a software application, then it is very uncertain whether anything of use will be delivered at all. And often budget is exceeded and any deliverables are likely to be quite different from expectations.
There are many reasons for this, but organizational culture is probably the one that summarizes well all the aspects involved. Mentality is also part of the organizational culture. For example, if a civil engineer under estimates the load bearing beam to cut costs, he would be sent to jail. (Again, Italy is notable exception here.) But if a software engineer cuts testing or development time to cut costs, he gets promoted. And, worse yet, this is just what most managers often ask for.
The mechanics of relationships between managers and development team should be refactored well before than refactoring code.
To be continued.
Hopefully this is only yet another poor story that can only happen in Italy. I suspect, however, it just reflects a common global pattern.
Someone–let’s call her Alice–sends me a LinkedIn request a few days ago. I’m close to 1,000 contacts and my policy I quite lazy on that. I pretty much accept any requests that makes minimally sense–you never know what can come out of it. (OK, I do have a sort of a farmer-inspired mentality :))
A few days later, the same recruiter–Alice, apparently young and pretty face–sends a message asking if I could be interested in applying for an ASP.NET developer position somewhere like 500+ km away from home. She copied to the bottom of the email a long list of hard-to-find requirements. Literally:
- Good knowledge of web application development
- Good knowledge of ASP.NET and C# languages
- Preferably, past experience in development of sites and portals
- Knowledge of the MVC pattern is a must
I’m not certainly active in IT recruitment, but my problem today seems to be quite the opposite: getting really good curricula for much stricter requirements.
As Alice was smart enough to find my contact on LinkedIn, was it so hard to make one more step and actually read my profile thoroughly? Or do recruiters think they’re the illuminated repositories of truth? Do they think maybe they’ve been given super powers because of their ability to give jobs?
Recruiter is a job–very delicate. And IT is a delicate industry; software engineering even more.
Who does actually recruit recruiters?
Jumping to the Android bandwagon is not an easy jump and for some reason it seems harder than it actually is. Developing for Android poses a number of additional issues that you nearly never face for other “stricter” platforms such as iOS and Windows Phone. At the same time, I don’t even think that the “freedom” of the Android world is a real benefit for the majority of developers.
Fact is, at some point you may face the need of writing Android apps. When it happens you then need to learn the basics of the programming model as well as the tools and frameworks that are either required or helpful. You may be pleased to know that JetBrains and Tuts+ managed to bring (me to bring) you a FREE (yes, free) course of Android programming just designed for the busy developer.
Busy means you “need” but hardly “have” the time to learn it step by step. So we created a learning path that doesn’t magically turn you into a guru; likewise, it won’t make you able to fork the Android OS or create drivers for it. However, if all you need is an app that does most of things that 80% of the apps out there do (things like data binding, remote data download, a bit of UI, preferences, menu, input forms, dialogs, page navigation) then your money (just kidding, it’s FREE) is well spent The course includes about 3 hours of content and illustrates examples in the context of IntelliJ IDEA Community Edition–the free IDE that Google’s Android Studio is based on.
Get “Android for the Busy Developer” today!