10 ms·

Professional Software Development

474 points by iris-digital 10y ago

mixmastamyk 10y ago
Author here, writing this book was one of the hardest things I've ever done, and there is seemingly no end to the small issues I've faced (both writing and technical). Would appreciate some feedback to make it as good as it can be, AMA thanks.
- RubenSandwich 10y ago
  First off great job, it looks like you put a bunch of hard work into this. One area for improvement is the images. Currently some of the more information dense ones are hard to read at small sizes and clicking on them does nothing. Perhaps expand them to full size on a click?
  - mixmastamyk 10y ago
    Good idea, thank you. In the meantime, you can right click and choose "view image" in your browser. Edit: have linked several dense images, thanks.
    - mixmastamyk 10y ago
      I had to back this out because of a conflict with the filesystem layout and strict epubcheck by itunes. :( Sorry. I did expand the dense image in the introduction to 100% width, which hopefully helps.
- daveslash 10y ago
  Only have skimmed it so far, but it looks great. Will look more soon. Off the bat though, I was looking at it on Amazon and the 'look inside' seems to scrunch up some of the text. Not sure if this is something an author can do anything about, but wanted to make you aware. I'm viewing this on Windows 10, Chrome 51, normal zoom level, and with minimal plugins. Screenshot: http://imgur.com/uXuELxv http://imgur.com/uXuELxv
  - mixmastamyk 10y ago
    Yes, I've seen this :-( thanks. Also Amazon currently doesn't handle the .svg images correctly, I have no solutions unfortunately, despite lots of googling. If anyone has any tips? Btw, besides the .svg problems, the kindle version looks fine otherwise on my iPhone, it is not squished, if that helps any.
    - machinshin_ 10y ago
      Checked out PrinceXML?
    - deleted 10y ago
      [deleted]
- NuDinNou 10y ago
  Will there be a PDF or an ePub version for this?
  - mixmastamyk 10y ago
    Yes, the version on iTunes is an epub. But they are not happy with the links to Amazon so I will have to remove them and put it back up. That will take a day or two, sorry. A pdf of the full book I'm not sure about yet, should I be concerned about copying? I'm new to authoring.
    - deleted 10y ago
      [deleted]
    - Fargren 10y ago
      DISCLAIMER: the following is my personal belief, and I don't have more than a few anecdotes to back it up. You shouldn't be concerned about copying no matter the format. Almost anyone who gets a copy of your book illegally is someone who would not have read your book at all if he couldn't have gotten it for free. And with these people, you are better of if they do get it; they may share it with someone who will become a customer, or they themselves may become customers in the future, when they learn that they like what you do and/or their purchasing habits change.
      - znpy 10y ago
        Can confirm: I usually "evaluate" books before buying them. Some books are really worth having on your bookshelf.
    - KevinEldon 10y ago
      Gumroad has a feature called PDF stamping [1] that puts the buyer's email address on the PDF. It's not perfect security, anyone who wants to ignore your copy rights probably will, but it might deter unthoughtful sharing. Also consider a team/company license priced at some multiple (15x?) that will allow a manager or lead to buy your book for their company/team without having to worry about violating copyrights or managing buying the book for every employee. [1] - http://blog.gumroad.com/post/40614820182/introducing-pdf-stamping http://blog.gumroad.com/post/40614820182/introducing-pdf-sta...
- ap22213 10y ago
  Wow - nice job! I just skimmed it, but it looks great - will read more later. With all the superficial, error-ridden, and rambling books being published these days (packt, etc.), it's a pleasure to see something information-dense, accurate, and also high-quality.
- tootie 10y ago
  Just looking at the intro and I see SDLC and cringe. Is this still applicable to agile practices?
  - mixmastamyk 10y ago
    Yes keep reading, it teaches you the "hard way" by starting at the beginning and moving forward. Try Ch. 7 - Models and Methodology, to skip to Agile.
  - TickleSteve 10y ago
    ...and very likely, in a few years time... people will see 'Agile' or 'sprint' and cringe.
    - mixmastamyk 10y ago
      And some are already cringing… I believe there have been a couple anti-agile posts here in the past month.
      - TickleSteve 10y ago
        not unjustifiably either... Agile has been so oversold, theres a big backlash against it coming....
    - superuser2 10y ago
      We'll cringe at the names, sure. I'll be very surprised if we actually go back to merging, integrating, testing, and releasing code once every few months/years instead of hours/days.
      - p4wnc6 10y ago
        Continuous delivery is orthogonal to any particular management ideology. There's nothing inherent to Agile that relates it to continuous delivery. You could interpret the Agile principles for the sake of delivering once a year releases if you wanted. And many firms do continuous delivery for very critical products and services without using Agile nor anything even remotely like Agile.
- perlgeek 10y ago
  Kudos for tackling such a huge range of topics! As a proponent of Continuous Delivery, I found the part on releases a bit old-fashioned and slightly disappointing. I can elaborate a bit more if you want, but most likely you're already familiar with the more iterative and automated approaches. Everybody has their pet peeves, I guess.
  - TickleSteve 10y ago
    You're thinking too much about web and desktop software. Software is often delivered with hardware or other services which have to have releases, hence releases are still very much a thing. software world > web software.
    - mixmastamyk 10y ago
      Yes, it tries to be useful for all types of software. Iterative/incremental is covered in chapter 7 under "gradual development." CI/CD under Construction and Quality. Also, to help understand the new, it helps to know the "old." At least that's what I thought. A number of people are mentioning it, so perhaps I shouldn't have ordered it that way.
  - mixmastamyk 10y ago
    > I can elaborate Yes, if you don't think the discussion in Ch. 7 is adequate.
- nickbauman 10y ago
  The separation of design and construction into phases is a hangover from civil engineering. It has the baked in assumption that the design phase is relatively cheap, short and somewhat unpredictable the construction phase is expensive, long and predictable. The root problem is the assumption that specifications can be validated for correctness, like a blueprint for a bridge can. Nothing could be further from the truth. This is a persistent myth in software development.
  - HenryTheHorse 10y ago
    > the design phase is relatively cheap In my world (enterprise software), the design phase is usually the most expensive phase, as it tends to be staffed with expensive architect/designer/technical lead-level folks.
  - mixmastamyk 10y ago
    Yes, it is often (mostly?) true, but not always. In the book I've tried to not give the idea there is only one way to do things. Even so, a few have commented that they've got that impression. Also, from a practical standpoint, both the design and construction chapters are huge, so combining them doesn't seem to be a good idea. Perhaps I could add your warning though, if you don't mind me quoting you.
    - nickbauman 10y ago
      I upvoted your comment even though (as a generalization) I disagree that these chapters should even exist as such. If were truly honest about the civil engineering metaphor as it applies to software, the design of a system is indeed the source code. The construction phase is done by the compiler. So your construction chapter should be about compilers and interpreters. Your design chapter should be about the explication of the stakeholder's intent in the form of human-readable code: the source code itself. What do you think?
      - mixmastamyk 10y ago
        Hmm, you've blown my mind. I've used traditional metaphors to describe and organize, such as the sdlc and topics like construction as defined by books like Code Complete. In other words, about/around these topics, not strictly limited to their concrete form or process. I suppose it isn't the only way to look at things, just common. Though we are approaching the philosophical realm at this point… reminds me of the section of Philosophy class where you learn to question if you can even trust your own senses. I'm not sure, however this is a book for beginners, and I sit on the shoulders of those that came before. Not sure I'm qualified to reimagine software engineering from the ground up as you describe. If you write that book, I'd read it!
- nickpsecurity 10y ago
  This comment... https://news.ycombinator.com/item?id=12081603 https://news.ycombinator.com/item?id=12081603 ...was meant for you. I knew you were in the thread but wrongly assumed you submitted the thread itself.
- danso 10y ago
  Thanks for writing and sharing this. It's not something I dived into deeply so feel free to ignore my opinion. But the main thing I feel this book lacks is a "show don't tell" mentality. I haven't read the content close enough to judge how insightful the technical nuts and bolts are. But one thing I learned only after working in software dev is the human aspect behind the pace and rhythm and success of projects. It's not just code and processes, but why such processes were implemented a n the first place. I'm violating my own principle, so I'll give an example: the book, Enterprise Rails, opens with a chapter titled, " The Tale of Twitter". Here's an excerpt: https://dan.chak.org/enterprise-rails/preface/ https://dan.chak.org/enterprise-rails/preface/ > Because Twitter was the largest, most public Rails site around, its stumbles were watched carefully, and the steps Twitter took to alleviate its scalability issues were thoroughly documented online. In one instance, the database was becoming a bottleneck. In response, Twitter added a 16 GB caching layer using Memcache to allow them to scale horizontally. Still, many queries involving complex joins were too slow. In response, the Twitter team started storing denormalized versions of the data for faster access. In a another instance, Twitter found its use of DRb, a mechanism for remote method invocation (RMI), had created a fragile single point of failure. It replaced DRb with Starling, a distributed messaging queue that gave it looser coupling of message producers and consumers, and better fault tolerance. > It is of no small significance that Twitter’s engineers chose to absolve Rails of being at fault for their problems; instead of offloading the blame to an external factor, they chose to take responsibility for their own design decisions. In fact, this was a wise choice. Twitter’s engineers knew that reimplementing the same architecture in a different language would have led to the same result of site outages and site sluggishness. But online rumor mills were abuzz with hints that Twitter was planning to dump Ruby and Rails as a platform. Twitter’s cofounder, Evan Williams, posted a tweet (shown in Figure 1 ) to assure everyone that Twitter had “no plans to abandon RoR.” It's not that every chapter should open up with a jaunty Malcolm Gladwell-seque tale about the life of loves of professional development. But some of your assertions could be made more compelled with some real-world examples: > As a student of computer science and programming, you’ve learned a significant portion of what you need to know as a rookie professional. The most difficult parts perhaps, but far from the “whole enchilada.” There's nothing wrong with that statement. But there's not much to it besides filler that students have been told for their entire college education. You yourself must have a few personal examples of what the first week of work taught you that 4 years of college didn't. And/or, you may remember a few interns who, despite their college pedigree, found themselves to be completely over their heads. Just even a couple of sentences of showing how you came to learn the wisdom you now dispense goes a long way. Anyway, sorry for the extended critique. I am obviously skipping over the part above to how damn hard it can be to find compelling stories :)
buckbova 10y ago
Definitely touch on a lot of topics here. And all looks well organized. It also does look like a laundry list of buzzwords and techspeak. Obviously this wouldn't be used to teach anyone any particular topic in detail but to get them familiar with the general concepts/steps involved in software dev. Edit: The two books I read that I thought covered these ideas well were Code Complete and Code Craft. But it's been about a decade now. Perhaps they're too dated.
- mixmastamyk 10y ago
  > It also does look like a laundry list of buzzwords and techspeak. Thanks, interesting. I've tried to define difficult terms, and it is aimed at a technical audience, but there is definitely room for improvement. If there are any readers having trouble, I'd appreciate hearing where. Will take a look myself as well.
  - buckbova 10y ago
    I picked the Design section to read first. Perhaps that one isn't as detailed as some of the others. I'm not trying to knock you here as I'm not exactly the audience for a publication of this type anyway. It does give a good idea about what you should know/be familiar with and a bunch of link outs to other sources on the web.
    - mixmastamyk 10y ago
      Yes, I think you're right. Design is such a huge topic and hard to condense into one chapter (one of the shorter). I will pull more details into it and perhaps others, thanks.
namiller2 10y ago
Why are you using Joy Division's Unknown Pleasures album as the cover of the book?
- mixmastamyk 10y ago
  It is a scientific image, I believe public domain. Happen to love music and you will find that reading the book. The cover is the first clue. ;) (More information is at the bottom of the intro/title page under Acknowledgements).
  - justinator 10y ago
    I guess, but it's lacking the dyadic relationship between the image and the music (or in your case: content). That's what made that album cover so great.
    - cutie 10y ago
      Are you drunk? You think a data plot has an intimate relationship with music but not software? Sounds like someone is romanticising. ;)
- arethuza 10y ago
  An album with tracks called "New Dawn Fades", " "Wilderness" and "Disorder" seems oddly appropriate for a book on Project Management... ;-) https://en.wikipedia.org/wiki/Unknown_Pleasures https://en.wikipedia.org/wiki/Unknown_Pleasures
- phonon 10y ago
  http://blogs.scientificamerican.com/sa-visual/pop-culture-pulsar-origin-story-of-joy-division-s-unknown-pleasures-album-cover-video/ http://blogs.scientificamerican.com/sa-visual/pop-culture-pu...
- Raphmedia 10y ago
  It's actually an old image of the radio pulses of a pulsar stacked on top of each other.
emptybits 10y ago
Thanks to the author -- it does like like your labour of love and written with some personality. (That's a good thing!) Attractive layout, lots of insets/quotes/diagrams, and sources. Will read more later. The "Models & Methodologies" chapters looks great. It may become my new "here, read this!" when people ask me "what's agile?" or "how else?" http://mixmastamyk.bitbucket.org/pro_soft_dev/models.html http://mixmastamyk.bitbucket.org/pro_soft_dev/models.html
- mixmastamyk 10y ago
  Thank you, I've tried to do exactly that, give new people a good overview with not too much information at once, and encourage further study with copious references.
Achshar 10y ago
Offtopic: How do I get that github.io type hosting for my own bitbucket account? I didn't know it was possible. Edit: It's as mixmastamyk says. I created a repo called 'achshar.bitbucket.org' and it works.
- mixmastamyk 10y ago
  You make a repo with the same name as the your user account and domain, e.g. user.bitbucket.org
  - Achshar 10y ago
    I already have such a repo. But I would reckon the repo needs to be open source right? What if I would like to host all my open source repos on that subdomain? Oh ok, it needs to be the entire url 'user.bitbucket.org'.
    - mixmastamyk 10y ago
      Don't believe there are restrictions, but only one repo resides at that url. Put in an index.html and it should be viewable by browser.
    - joelg236 10y ago
      It doesn't need to be open source, no. It will host anything in the repo as static content, even if the repo is private.
- jgowans 10y ago
  You can use the Aerobatic add-on for Bitbucket https://www.aerobatic.com/ https://www.aerobatic.com/ SSL, custom domains, static generator auto-builds, etc. disclaimer: co-founder of Aerobatic
  - kannonboy 10y ago
    I'm an Atlassian engineer & heavy Aerobatic user. It's very nicely integrated with Bitbucket, and has great support for Jekyll, Hugo, and arbitrary npm builds. It also has some advantages over github.io like being able to deploy multiple feature branches from the same repository to separate sites, so you can have separate "staging" and "production" versions. It is a paid offering, though you get two repositories free, and is very pretty reasonably priced beyond that.
DougWebb 10y ago
In a book like this, I'd like to see cost estimation mentioned earlier than Chapter 8. I'd argue that in nearly all software development projects (particularly the ones where this sort of book applies) the cost of implementation is one of the key factors in evaluating requirements. If you put together your requirements without considering their cost, you end up with a project that's too expensive to build, and you want to know that during the Requirements Gathering phase, not later on during construction. Even Agile projects need to start out with a rough idea of what's being built and a rough idea of what it'll cost to build it. Otherwise how does the person funding the project decide whether or not to approve it? Of course, as we all know providing estimates during the requirements phase is very difficult, especially if they're treated as hard commitments rather than rough ballparks. Chapter 2 mentions that getting requirements wrong is a key factor in causing software projects to fail; I'd say that the reason for that is usually because of the implementation costs of the known requirements that were estimated inaccurately or not at all, and the implementation costs of requirements that aren't discovered until later. It always comes down to cost; I think it's relatively rare for a software project to fail because a requirement turned out to be impossible to implement. (Unless it involves AI. You always have to watch for people trying to sneak in an AI requirement.)
- manyxcxi 10y ago
  At my uni our Software Engineering I (CS301 or maybe it was II[CS302]) class was entirely based on requirements gathering and estimation. It was a real eye opener for me- I'd been writing code in many languages since I was 10, but this was my first glimpse at "that other stuff" that takes up the majority of one's day. All in all, I feel like it prepared me for what I would face in the real world. We had to do stakeholder interviews where the professor or a TA played the role of unforthcoming/neurotic stakeholder, were introduced to various general document types like stakeholder analysis, cost/benefit analysis, requirements overviews, etc. and the last 1/3 was pretty much applying all the interviews and data to an estimation process. We also did a greenfield project, an additional functionality project, and a system replacement project to work through the pitfalls of each. I also think it was the first time I read The Mythical Man Month and Waltzing with Bears. The two things, by far, that stick out about recent college grads (or really, new developers in general) are the inability to estimate and gather requirements and a complete lack of knowledge around source control. GitHub and a lot of projects that are based around checking project source out has made a lot of Junior devs more familiar with at least the idea of source control, but very little prepares them for the flailing and hand wringing that comes with estimation.
dboreham 10y ago
I like this book as a means to present the ways people describe how software is developed. However, as I read I'm itching to annotate it with notes on "what really happens". I've worked in this business for a few decades now, in various locations and various sizes of companies, including a few that are household names. I have NEVER seen software built on the ground in exactly the ways one sees documented (documented anywhere, not just in this book). A couple of things I don't see mentioned (apologies if they're in there, I haven't read every word): 1. Process does (and should) vary tremendously depending on factors including the organization size, organization maturity, market maturity, experience level of the people involved, budget, etc. The book seems to suggest that there's a one-process-to-rule-them-all. 2. Often there are significant unknowns about a project : unknown technologies, unknown market needs, unknown requirements. Being able to accommodate the unknowns, which can mean not expending effort trying to know something unknowable, is important. The book I think gives an impression of quite confident smooth progress toward project completion that I personally have never observed. Also: The value of Rubber Chickens is not mentioned...
- dankohn1 10y ago
  It's taking you so long to fix bugs because you're doing it wrong! You need to use a duck, not a chicken. Even Wikipedia agrees: https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging
  - wnoise 10y ago
    Wikipedia is wrong. You need a stuffed teddy bear. Everyone benefits by consulting the wisdom of the bugbear.
    - dkersten 10y ago
      I just ask my cats for help. They look at me funny as if I'm crazy and then I try again with renewed vigour.
      - 10y ago
nickpsecurity 10y ago
Here's some for you collection given I see some omissions. Cleanroom, always omitted (sighs), is a big one as it was doing agile-like development in 80's with code so reliable it was sometimes warrantied. Also one of first, formal methods that didn't require a mathematician to use. Fagan's Software Inspection Process came before that in the 70's. I throw in Praxis and 001 for good measure as they're engineered software methods with better results than Cleanroom albeit at higher cost. Leave off plenty of others too constrained for most software development but did prove out in smaller projects. The B Method & Chlipala's Certified Programming in Coq are examples if you want to Google around. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.2667&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.... Note: An academic recently combined Cleanroom with Python for some nice results given how high-level Python is. I thought Haskell would be more ideal. https://en.wikipedia.org/wiki/Major_Defect https://en.wikipedia.org/wiki/Major_Defect Note: Describes Fagan process with relevant links. http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruction.pdf http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruct... Note: Altran/Praxis Correct by Construction is a modern high-assurance method with numerous successes. Cost a 50% premium for nearly defect-free systems. SPARK Ada is GPL these days. http://htius.com/Articles/articles.htm http://htius.com/Articles/articles.htm Note: Margaret Hamilton, who helped invent software engineering on Apollo mission, deserves mention for the first tool that automated most of software process. You can spec a whole system... one company specified their whole factory haha... then it semi-automates design then automatically does code, testing, portability, requirements traces, and so on. Guarantees no interface errors, which are 80+% of software faults. Today's tools have better notations & performance but still can't do all that for general-purpose systems: always a niche. https://www.eiffel.com/values/design-by-contract/introduction/ https://www.eiffel.com/values/design-by-contract/introductio... Note: Added Eiffel method to make up for fact that I have little to nothing on OOP given I don't use OOP. Meyer et al get credit for a powerful combo of language features and methodology in Eiffel platform with huge impact on software. Specifically, Design-by-Contract has so many benefits that even SPARK and Ada both added it to their languages. Just knocks out all kinds of problems plus can support automated generation of tests and such. So, there's you some reading on methods of making robust software that might fit into your book or something else you do. :)
- 10y ago
kennethjiang 10y ago
Kudos to the author for tackling this huge and controversial topic. Read first several chapters and picked up the impression that the author doesn't put enough effort to point out how the processes/practices can (and should) be completely different depending on the circumstances. If a startup tries to use the same processes as Google or Facebook, it'll be dead in the water. If SpaceX engineers write software the same way as SnapChat does it, we will never see their rockets leaving launch pads.
- mixmastamyk 10y ago
  Thank you. I'm going to beef that up in the introduction, due to several comments such as yours. May I quote you?
Morendil 10y ago
I'm disappointed to see a book aimed at "professional" developers continue to spread outdated and debunked information, such as the NIST "study" adduced as evidence for the imperative necessity of "defect cost containment". See my post on the topic: https://plus.google.com/+LaurentBossavit/posts/8QLBPXA9miZ https://plus.google.com/+LaurentBossavit/posts/8QLBPXA9miZ Or again the Wikipedia page on the history of software engineering, which is frightfully inadequate. https://plus.google.com/+LaurentBossavit/posts/gpSwoWn4CBK https://plus.google.com/+LaurentBossavit/posts/gpSwoWn4CBK I'll add my voice to those that have already stated such a book shouldn't start by assuming the SDLC as a reference model: it embodies too many of those outdated assumptions. More in that vein in my own book http://leanpub.com/leprechauns http://leanpub.com/leprechauns
- agentultra 10y ago
  I haven't read all of it yet but it also seems to miss the vein of development that has led to movements such as Correct by Construction et al. The idea that we should model our computations in a high-level specification and check that those designs meet our goals and hold the invariants we press upon them. Instead there's Agile and the idea that we can throw together something that roughly works and iterate until our confidence is enough such that we can release it. The so-called, beta-driven-development. (Perhaps a vestigial remnant of the unix philosophy?). I'm not arguing that formal methods should be used for every software project. I think Carmack was right to point out that if all software was written like the software at JPL we'd be decades behind where we are now. However I do think that it should be a part of the experience of becoming a programmer so that when we encounter hard problems we have the correct instincts to rely on mathematics to help us.
  - mixmastamyk 10y ago
    This is a beginners book, and keeping in mind we can't teach them everything in the first "semester," do you still think this topic should be included?
    - agentultra 10y ago
mixmastamyk 10y ago
Thanks all for the great discussion and feedback, I've already incorporated much of it and will continue to improve the weaker sections.
ecesena 10y ago
The double icon for external links to youtube|wikipedia|twitter etc. seems superfluous and makes things harder to read.
- mixmastamyk 10y ago
  I'll take a look at toning that down tomorrow.
ascotan 10y ago
Interesting book. I'll take some time to do a read through. A few things that bother me though off the bat: 1. Anything that uses the word 'protip' can not be taken seriously. I think this needs a law. 'The Law Of Silly Programming Memes - Anything using the word 'protip' cannot be taken seriously' 2. The 800px width format in the world of responsive design gives me pause. Basically this says 'I'm for mobile - screw you'. I would hope that a better format for this would be chosen in the future.
- mixmastamyk 10y ago
  Oh, always read "protip" on reddit with a smile. It is aimed at the young, sounds like you're being a bit chatinho. Also thought it was recognized that narrow columns are easier to read, such as in a newspaper. It uses the well-regarded "read the docs" theme. Maybe zoom would help?
fncodr 10y ago
I'm not trying to hurt you, I'm not jealous, not out to stroke my ego. I can sense this is your way of reaching out, that you feel something is not right. And I applaud the effort. But no one needs one more speaker repeating the same old stupid message; the holy grail is the synthesis of experience and knowledge, wisdom. I don't know if it's because of a lack of actual creative coding experience or lack of time/space/inclination to reflect; but this looks like mostly rehashing half baked "truths" from the past... Effective software design begins with the establishment of clear, achievable, and unambiguous requirements. — IEEE Computer Society, on Requirements Bullshit, really. If you can specify your system clearly and unambiguously from the start it already exists; and your energy would probably be better spent elsewhere, professionally or not. That's what agile managed to get right before it was infiltrated by the process nazis and turned into a thousand ways to nail Kent Beck to a cross. Dare to reach within, trust your experience. Tell us what you really think. Peace

474 points by iris-digital 10y ago

Author here, writing this book was one of the hardest things I've ever done, and there is seemingly no end to the small issues I've faced (both writing and technical). Would appreciate some feedback to make it as good as it can be, AMA thanks.

RubenSandwich 10y ago
First off great job, it looks like you put a bunch of hard work into this. One area for improvement is the images. Currently some of the more information dense ones are hard to read at small sizes and clicking on them does nothing. Perhaps expand them to full size on a click?
- mixmastamyk 10y ago
  Good idea, thank you. In the meantime, you can right click and choose "view image" in your browser. Edit: have linked several dense images, thanks.
  - mixmastamyk 10y ago
    I had to back this out because of a conflict with the filesystem layout and strict epubcheck by itunes. :( Sorry. I did expand the dense image in the introduction to 100% width, which hopefully helps.
daveslash 10y ago
Only have skimmed it so far, but it looks great. Will look more soon. Off the bat though, I was looking at it on Amazon and the 'look inside' seems to scrunch up some of the text. Not sure if this is something an author can do anything about, but wanted to make you aware. I'm viewing this on Windows 10, Chrome 51, normal zoom level, and with minimal plugins. Screenshot: http://imgur.com/uXuELxv http://imgur.com/uXuELxv
- mixmastamyk 10y ago
  Yes, I've seen this :-( thanks. Also Amazon currently doesn't handle the .svg images correctly, I have no solutions unfortunately, despite lots of googling. If anyone has any tips? Btw, besides the .svg problems, the kindle version looks fine otherwise on my iPhone, it is not squished, if that helps any.
  - machinshin_ 10y ago
    Checked out PrinceXML?
  - deleted 10y ago
    [deleted]
NuDinNou 10y ago
Will there be a PDF or an ePub version for this?
- mixmastamyk 10y ago
  Yes, the version on iTunes is an epub. But they are not happy with the links to Amazon so I will have to remove them and put it back up. That will take a day or two, sorry. A pdf of the full book I'm not sure about yet, should I be concerned about copying? I'm new to authoring.
  - deleted 10y ago
    [deleted]
  - Fargren 10y ago
    DISCLAIMER: the following is my personal belief, and I don't have more than a few anecdotes to back it up. You shouldn't be concerned about copying no matter the format. Almost anyone who gets a copy of your book illegally is someone who would not have read your book at all if he couldn't have gotten it for free. And with these people, you are better of if they do get it; they may share it with someone who will become a customer, or they themselves may become customers in the future, when they learn that they like what you do and/or their purchasing habits change.
    - znpy 10y ago
      Can confirm: I usually "evaluate" books before buying them. Some books are really worth having on your bookshelf.
  - KevinEldon 10y ago
    Gumroad has a feature called PDF stamping [1] that puts the buyer's email address on the PDF. It's not perfect security, anyone who wants to ignore your copy rights probably will, but it might deter unthoughtful sharing. Also consider a team/company license priced at some multiple (15x?) that will allow a manager or lead to buy your book for their company/team without having to worry about violating copyrights or managing buying the book for every employee. [1] - http://blog.gumroad.com/post/40614820182/introducing-pdf-stamping http://blog.gumroad.com/post/40614820182/introducing-pdf-sta...
ap22213 10y ago
Wow - nice job! I just skimmed it, but it looks great - will read more later. With all the superficial, error-ridden, and rambling books being published these days (packt, etc.), it's a pleasure to see something information-dense, accurate, and also high-quality.
tootie 10y ago
Just looking at the intro and I see SDLC and cringe. Is this still applicable to agile practices?
- mixmastamyk 10y ago
  Yes keep reading, it teaches you the "hard way" by starting at the beginning and moving forward. Try Ch. 7 - Models and Methodology, to skip to Agile.
- TickleSteve 10y ago
  ...and very likely, in a few years time... people will see 'Agile' or 'sprint' and cringe.
  - mixmastamyk 10y ago
    And some are already cringing… I believe there have been a couple anti-agile posts here in the past month.
    - TickleSteve 10y ago
      not unjustifiably either... Agile has been so oversold, theres a big backlash against it coming....
  - superuser2 10y ago
    We'll cringe at the names, sure. I'll be very surprised if we actually go back to merging, integrating, testing, and releasing code once every few months/years instead of hours/days.
    - p4wnc6 10y ago
      Continuous delivery is orthogonal to any particular management ideology. There's nothing inherent to Agile that relates it to continuous delivery. You could interpret the Agile principles for the sake of delivering once a year releases if you wanted. And many firms do continuous delivery for very critical products and services without using Agile nor anything even remotely like Agile.
perlgeek 10y ago
Kudos for tackling such a huge range of topics! As a proponent of Continuous Delivery, I found the part on releases a bit old-fashioned and slightly disappointing. I can elaborate a bit more if you want, but most likely you're already familiar with the more iterative and automated approaches. Everybody has their pet peeves, I guess.
- TickleSteve 10y ago
  You're thinking too much about web and desktop software. Software is often delivered with hardware or other services which have to have releases, hence releases are still very much a thing. software world > web software.
  - mixmastamyk 10y ago
    Yes, it tries to be useful for all types of software. Iterative/incremental is covered in chapter 7 under "gradual development." CI/CD under Construction and Quality. Also, to help understand the new, it helps to know the "old." At least that's what I thought. A number of people are mentioning it, so perhaps I shouldn't have ordered it that way.
- mixmastamyk 10y ago
  > I can elaborate Yes, if you don't think the discussion in Ch. 7 is adequate.
nickbauman 10y ago
The separation of design and construction into phases is a hangover from civil engineering. It has the baked in assumption that the design phase is relatively cheap, short and somewhat unpredictable the construction phase is expensive, long and predictable. The root problem is the assumption that specifications can be validated for correctness, like a blueprint for a bridge can. Nothing could be further from the truth. This is a persistent myth in software development.
- HenryTheHorse 10y ago
  > the design phase is relatively cheap In my world (enterprise software), the design phase is usually the most expensive phase, as it tends to be staffed with expensive architect/designer/technical lead-level folks.
- mixmastamyk 10y ago
  Yes, it is often (mostly?) true, but not always. In the book I've tried to not give the idea there is only one way to do things. Even so, a few have commented that they've got that impression. Also, from a practical standpoint, both the design and construction chapters are huge, so combining them doesn't seem to be a good idea. Perhaps I could add your warning though, if you don't mind me quoting you.
  - nickbauman 10y ago
    I upvoted your comment even though (as a generalization) I disagree that these chapters should even exist as such. If were truly honest about the civil engineering metaphor as it applies to software, the design of a system is indeed the source code. The construction phase is done by the compiler. So your construction chapter should be about compilers and interpreters. Your design chapter should be about the explication of the stakeholder's intent in the form of human-readable code: the source code itself. What do you think?
    - mixmastamyk 10y ago
      Hmm, you've blown my mind. I've used traditional metaphors to describe and organize, such as the sdlc and topics like construction as defined by books like Code Complete. In other words, about/around these topics, not strictly limited to their concrete form or process. I suppose it isn't the only way to look at things, just common. Though we are approaching the philosophical realm at this point… reminds me of the section of Philosophy class where you learn to question if you can even trust your own senses. I'm not sure, however this is a book for beginners, and I sit on the shoulders of those that came before. Not sure I'm qualified to reimagine software engineering from the ground up as you describe. If you write that book, I'd read it!
nickpsecurity 10y ago
This comment... https://news.ycombinator.com/item?id=12081603 https://news.ycombinator.com/item?id=12081603 ...was meant for you. I knew you were in the thread but wrongly assumed you submitted the thread itself.
danso 10y ago
Thanks for writing and sharing this. It's not something I dived into deeply so feel free to ignore my opinion. But the main thing I feel this book lacks is a "show don't tell" mentality. I haven't read the content close enough to judge how insightful the technical nuts and bolts are. But one thing I learned only after working in software dev is the human aspect behind the pace and rhythm and success of projects. It's not just code and processes, but why such processes were implemented a n the first place. I'm violating my own principle, so I'll give an example: the book, Enterprise Rails, opens with a chapter titled, " The Tale of Twitter". Here's an excerpt: https://dan.chak.org/enterprise-rails/preface/ https://dan.chak.org/enterprise-rails/preface/ > Because Twitter was the largest, most public Rails site around, its stumbles were watched carefully, and the steps Twitter took to alleviate its scalability issues were thoroughly documented online. In one instance, the database was becoming a bottleneck. In response, Twitter added a 16 GB caching layer using Memcache to allow them to scale horizontally. Still, many queries involving complex joins were too slow. In response, the Twitter team started storing denormalized versions of the data for faster access. In a another instance, Twitter found its use of DRb, a mechanism for remote method invocation (RMI), had created a fragile single point of failure. It replaced DRb with Starling, a distributed messaging queue that gave it looser coupling of message producers and consumers, and better fault tolerance. > It is of no small significance that Twitter’s engineers chose to absolve Rails of being at fault for their problems; instead of offloading the blame to an external factor, they chose to take responsibility for their own design decisions. In fact, this was a wise choice. Twitter’s engineers knew that reimplementing the same architecture in a different language would have led to the same result of site outages and site sluggishness. But online rumor mills were abuzz with hints that Twitter was planning to dump Ruby and Rails as a platform. Twitter’s cofounder, Evan Williams, posted a tweet (shown in Figure 1 ) to assure everyone that Twitter had “no plans to abandon RoR.” It's not that every chapter should open up with a jaunty Malcolm Gladwell-seque tale about the life of loves of professional development. But some of your assertions could be made more compelled with some real-world examples: > As a student of computer science and programming, you’ve learned a significant portion of what you need to know as a rookie professional. The most difficult parts perhaps, but far from the “whole enchilada.” There's nothing wrong with that statement. But there's not much to it besides filler that students have been told for their entire college education. You yourself must have a few personal examples of what the first week of work taught you that 4 years of college didn't. And/or, you may remember a few interns who, despite their college pedigree, found themselves to be completely over their heads. Just even a couple of sentences of showing how you came to learn the wisdom you now dispense goes a long way. Anyway, sorry for the extended critique. I am obviously skipping over the part above to how damn hard it can be to find compelling stories :)

buckbova 10y ago

Definitely touch on a lot of topics here. And all looks well organized. It also does look like a laundry list of buzzwords and techspeak. Obviously this wouldn't be used to teach anyone any particular topic in detail but to get them familiar with the general concepts/steps involved in software dev. Edit: The two books I read that I thought covered these ideas well were Code Complete and Code Craft. But it's been about a decade now. Perhaps they're too dated.

mixmastamyk 10y ago
> It also does look like a laundry list of buzzwords and techspeak. Thanks, interesting. I've tried to define difficult terms, and it is aimed at a technical audience, but there is definitely room for improvement. If there are any readers having trouble, I'd appreciate hearing where. Will take a look myself as well.
- buckbova 10y ago
  I picked the Design section to read first. Perhaps that one isn't as detailed as some of the others. I'm not trying to knock you here as I'm not exactly the audience for a publication of this type anyway. It does give a good idea about what you should know/be familiar with and a bunch of link outs to other sources on the web.
  - mixmastamyk 10y ago
    Yes, I think you're right. Design is such a huge topic and hard to condense into one chapter (one of the shorter). I will pull more details into it and perhaps others, thanks.

namiller2 10y ago

Why are you using Joy Division's Unknown Pleasures album as the cover of the book?

mixmastamyk 10y ago
It is a scientific image, I believe public domain. Happen to love music and you will find that reading the book. The cover is the first clue. ;) (More information is at the bottom of the intro/title page under Acknowledgements).
- justinator 10y ago
  I guess, but it's lacking the dyadic relationship between the image and the music (or in your case: content). That's what made that album cover so great.
  - cutie 10y ago
    Are you drunk? You think a data plot has an intimate relationship with music but not software? Sounds like someone is romanticising. ;)
arethuza 10y ago
An album with tracks called "New Dawn Fades", " "Wilderness" and "Disorder" seems oddly appropriate for a book on Project Management... ;-) https://en.wikipedia.org/wiki/Unknown_Pleasures https://en.wikipedia.org/wiki/Unknown_Pleasures
phonon 10y ago
http://blogs.scientificamerican.com/sa-visual/pop-culture-pulsar-origin-story-of-joy-division-s-unknown-pleasures-album-cover-video/ http://blogs.scientificamerican.com/sa-visual/pop-culture-pu...
Raphmedia 10y ago
It's actually an old image of the radio pulses of a pulsar stacked on top of each other.

emptybits 10y ago

Thanks to the author -- it does like like your labour of love and written with some personality. (That's a good thing!) Attractive layout, lots of insets/quotes/diagrams, and sources. Will read more later. The "Models & Methodologies" chapters looks great. It may become my new "here, read this!" when people ask me "what's agile?" or "how else?" http://mixmastamyk.bitbucket.org/pro_soft_dev/models.html http://mixmastamyk.bitbucket.org/pro_soft_dev/models.html

mixmastamyk 10y ago
Thank you, I've tried to do exactly that, give new people a good overview with not too much information at once, and encourage further study with copious references.

Achshar 10y ago

Offtopic: How do I get that github.io type hosting for my own bitbucket account? I didn't know it was possible. Edit: It's as mixmastamyk says. I created a repo called 'achshar.bitbucket.org' and it works.

mixmastamyk 10y ago
You make a repo with the same name as the your user account and domain, e.g. user.bitbucket.org
- Achshar 10y ago
  I already have such a repo. But I would reckon the repo needs to be open source right? What if I would like to host all my open source repos on that subdomain? Oh ok, it needs to be the entire url 'user.bitbucket.org'.
  - mixmastamyk 10y ago
    Don't believe there are restrictions, but only one repo resides at that url. Put in an index.html and it should be viewable by browser.
  - joelg236 10y ago
    It doesn't need to be open source, no. It will host anything in the repo as static content, even if the repo is private.
jgowans 10y ago
You can use the Aerobatic add-on for Bitbucket https://www.aerobatic.com/ https://www.aerobatic.com/ SSL, custom domains, static generator auto-builds, etc. disclaimer: co-founder of Aerobatic
- kannonboy 10y ago
  I'm an Atlassian engineer & heavy Aerobatic user. It's very nicely integrated with Bitbucket, and has great support for Jekyll, Hugo, and arbitrary npm builds. It also has some advantages over github.io like being able to deploy multiple feature branches from the same repository to separate sites, so you can have separate "staging" and "production" versions. It is a paid offering, though you get two repositories free, and is very pretty reasonably priced beyond that.

DougWebb 10y ago

In a book like this, I'd like to see cost estimation mentioned earlier than Chapter 8. I'd argue that in nearly all software development projects (particularly the ones where this sort of book applies) the cost of implementation is one of the key factors in evaluating requirements. If you put together your requirements without considering their cost, you end up with a project that's too expensive to build, and you want to know that during the Requirements Gathering phase, not later on during construction. Even Agile projects need to start out with a rough idea of what's being built and a rough idea of what it'll cost to build it. Otherwise how does the person funding the project decide whether or not to approve it? Of course, as we all know providing estimates during the requirements phase is very difficult, especially if they're treated as hard commitments rather than rough ballparks. Chapter 2 mentions that getting requirements wrong is a key factor in causing software projects to fail; I'd say that the reason for that is usually because of the implementation costs of the known requirements that were estimated inaccurately or not at all, and the implementation costs of requirements that aren't discovered until later. It always comes down to cost; I think it's relatively rare for a software project to fail because a requirement turned out to be impossible to implement. (Unless it involves AI. You always have to watch for people trying to sneak in an AI requirement.)

manyxcxi 10y ago
At my uni our Software Engineering I (CS301 or maybe it was II[CS302]) class was entirely based on requirements gathering and estimation. It was a real eye opener for me- I'd been writing code in many languages since I was 10, but this was my first glimpse at "that other stuff" that takes up the majority of one's day. All in all, I feel like it prepared me for what I would face in the real world. We had to do stakeholder interviews where the professor or a TA played the role of unforthcoming/neurotic stakeholder, were introduced to various general document types like stakeholder analysis, cost/benefit analysis, requirements overviews, etc. and the last 1/3 was pretty much applying all the interviews and data to an estimation process. We also did a greenfield project, an additional functionality project, and a system replacement project to work through the pitfalls of each. I also think it was the first time I read The Mythical Man Month and Waltzing with Bears. The two things, by far, that stick out about recent college grads (or really, new developers in general) are the inability to estimate and gather requirements and a complete lack of knowledge around source control. GitHub and a lot of projects that are based around checking project source out has made a lot of Junior devs more familiar with at least the idea of source control, but very little prepares them for the flailing and hand wringing that comes with estimation.

dboreham 10y ago

I like this book as a means to present the ways people describe how software is developed. However, as I read I'm itching to annotate it with notes on "what really happens". I've worked in this business for a few decades now, in various locations and various sizes of companies, including a few that are household names. I have NEVER seen software built on the ground in exactly the ways one sees documented (documented anywhere, not just in this book). A couple of things I don't see mentioned (apologies if they're in there, I haven't read every word): 1. Process does (and should) vary tremendously depending on factors including the organization size, organization maturity, market maturity, experience level of the people involved, budget, etc. The book seems to suggest that there's a one-process-to-rule-them-all. 2. Often there are significant unknowns about a project : unknown technologies, unknown market needs, unknown requirements. Being able to accommodate the unknowns, which can mean not expending effort trying to know something unknowable, is important. The book I think gives an impression of quite confident smooth progress toward project completion that I personally have never observed. Also: The value of Rubber Chickens is not mentioned...

dankohn1 10y ago
It's taking you so long to fix bugs because you're doing it wrong! You need to use a duck, not a chicken. Even Wikipedia agrees: https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging
- wnoise 10y ago
  Wikipedia is wrong. You need a stuffed teddy bear. Everyone benefits by consulting the wisdom of the bugbear.
  - dkersten 10y ago
    I just ask my cats for help. They look at me funny as if I'm crazy and then I try again with renewed vigour.
    - 10y ago

nickpsecurity 10y ago

Here's some for you collection given I see some omissions. Cleanroom, always omitted (sighs), is a big one as it was doing agile-like development in 80's with code so reliable it was sometimes warrantied. Also one of first, formal methods that didn't require a mathematician to use. Fagan's Software Inspection Process came before that in the 70's. I throw in Praxis and 001 for good measure as they're engineered software methods with better results than Cleanroom albeit at higher cost. Leave off plenty of others too constrained for most software development but did prove out in smaller projects. The B Method & Chlipala's Certified Programming in Coq are examples if you want to Google around. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.2667&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.... Note: An academic recently combined Cleanroom with Python for some nice results given how high-level Python is. I thought Haskell would be more ideal. https://en.wikipedia.org/wiki/Major_Defect https://en.wikipedia.org/wiki/Major_Defect Note: Describes Fagan process with relevant links. http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruction.pdf http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruct... Note: Altran/Praxis Correct by Construction is a modern high-assurance method with numerous successes. Cost a 50% premium for nearly defect-free systems. SPARK Ada is GPL these days. http://htius.com/Articles/articles.htm http://htius.com/Articles/articles.htm Note: Margaret Hamilton, who helped invent software engineering on Apollo mission, deserves mention for the first tool that automated most of software process. You can spec a whole system... one company specified their whole factory haha... then it semi-automates design then automatically does code, testing, portability, requirements traces, and so on. Guarantees no interface errors, which are 80+% of software faults. Today's tools have better notations & performance but still can't do all that for general-purpose systems: always a niche. https://www.eiffel.com/values/design-by-contract/introduction/ https://www.eiffel.com/values/design-by-contract/introductio... Note: Added Eiffel method to make up for fact that I have little to nothing on OOP given I don't use OOP. Meyer et al get credit for a powerful combo of language features and methodology in Eiffel platform with huge impact on software. Specifically, Design-by-Contract has so many benefits that even SPARK and Ada both added it to their languages. Just knocks out all kinds of problems plus can support automated generation of tests and such. So, there's you some reading on methods of making robust software that might fit into your book or something else you do. :)

10y ago

kennethjiang 10y ago

Kudos to the author for tackling this huge and controversial topic. Read first several chapters and picked up the impression that the author doesn't put enough effort to point out how the processes/practices can (and should) be completely different depending on the circumstances. If a startup tries to use the same processes as Google or Facebook, it'll be dead in the water. If SpaceX engineers write software the same way as SnapChat does it, we will never see their rockets leaving launch pads.

mixmastamyk 10y ago
Thank you. I'm going to beef that up in the introduction, due to several comments such as yours. May I quote you?

Morendil 10y ago

I'm disappointed to see a book aimed at "professional" developers continue to spread outdated and debunked information, such as the NIST "study" adduced as evidence for the imperative necessity of "defect cost containment". See my post on the topic: https://plus.google.com/+LaurentBossavit/posts/8QLBPXA9miZ https://plus.google.com/+LaurentBossavit/posts/8QLBPXA9miZ Or again the Wikipedia page on the history of software engineering, which is frightfully inadequate. https://plus.google.com/+LaurentBossavit/posts/gpSwoWn4CBK https://plus.google.com/+LaurentBossavit/posts/gpSwoWn4CBK I'll add my voice to those that have already stated such a book shouldn't start by assuming the SDLC as a reference model: it embodies too many of those outdated assumptions. More in that vein in my own book http://leanpub.com/leprechauns http://leanpub.com/leprechauns

agentultra 10y ago
I haven't read all of it yet but it also seems to miss the vein of development that has led to movements such as Correct by Construction et al. The idea that we should model our computations in a high-level specification and check that those designs meet our goals and hold the invariants we press upon them. Instead there's Agile and the idea that we can throw together something that roughly works and iterate until our confidence is enough such that we can release it. The so-called, beta-driven-development. (Perhaps a vestigial remnant of the unix philosophy?). I'm not arguing that formal methods should be used for every software project. I think Carmack was right to point out that if all software was written like the software at JPL we'd be decades behind where we are now. However I do think that it should be a part of the experience of becoming a programmer so that when we encounter hard problems we have the correct instincts to rely on mathematics to help us.
- mixmastamyk 10y ago
  This is a beginners book, and keeping in mind we can't teach them everything in the first "semester," do you still think this topic should be included?
  - agentultra 10y ago

mixmastamyk 10y ago

Thanks all for the great discussion and feedback, I've already incorporated much of it and will continue to improve the weaker sections.

ecesena 10y ago

The double icon for external links to youtube|wikipedia|twitter etc. seems superfluous and makes things harder to read.

mixmastamyk 10y ago
I'll take a look at toning that down tomorrow.

ascotan 10y ago

Interesting book. I'll take some time to do a read through. A few things that bother me though off the bat: 1. Anything that uses the word 'protip' can not be taken seriously. I think this needs a law. 'The Law Of Silly Programming Memes - Anything using the word 'protip' cannot be taken seriously' 2. The 800px width format in the world of responsive design gives me pause. Basically this says 'I'm for mobile - screw you'. I would hope that a better format for this would be chosen in the future.

mixmastamyk 10y ago
Oh, always read "protip" on reddit with a smile. It is aimed at the young, sounds like you're being a bit chatinho. Also thought it was recognized that narrow columns are easier to read, such as in a newspaper. It uses the well-regarded "read the docs" theme. Maybe zoom would help?

fncodr 10y ago

I'm not trying to hurt you, I'm not jealous, not out to stroke my ego. I can sense this is your way of reaching out, that you feel something is not right. And I applaud the effort. But no one needs one more speaker repeating the same old stupid message; the holy grail is the synthesis of experience and knowledge, wisdom. I don't know if it's because of a lack of actual creative coding experience or lack of time/space/inclination to reflect; but this looks like mostly rehashing half baked "truths" from the past... Effective software design begins with the establishment of clear, achievable, and unambiguous requirements. — IEEE Computer Society, on Requirements Bullshit, really. If you can specify your system clearly and unambiguously from the start it already exists; and your energy would probably be better spent elsewhere, professionally or not. That's what agile managed to get right before it was infiltrated by the process nazis and turned into a thousand ways to nail Kent Beck to a cross. Dare to reach within, trust your experience. Tell us what you really think. Peace